Progress of a chef run


#1

Guys, is there a mechanism (maybe a chef handler trick) so that I can report
(in a file for ex) the report of a long running chef run?

Cheers
Lucian


#2

Take a look at this handler:


-M

On Tuesday, August 6, 2013, wrote:

Guys, is there a mechanism (maybe a chef handler trick) so that I can
report
(in a file for ex) the report of a long running chef run?

Cheers
Lucian


#3

I might have not been clear.
Let’s say I start a chef run with 1k recipes and it will take 24h to
execute, is there a callback mechanism that chef uses while the run is in
progress, not after its completion as is the case with report handlers? I
want to be able to say to the user at one moment that “55 out of 1000
resources executed”.

Lucian

On Tue, Aug 6, 2013 at 2:29 PM, Mike miketheman@gmail.com wrote:

Take a look at this handler:
https://github.com/jamesc/chef-handler-elapsed-time
-M

On Tuesday, August 6, 2013, wrote:

Guys, is there a mechanism (maybe a chef handler trick) so that I can
report
(in a file for ex) the report of a long running chef run?

Cheers
Lucian


#4

On 8/8/2013 6:33 AM, Lucian Ciufudean wrote:

I might have not been clear.
Let’s say I start a chef run with 1k recipes and it will take 24h to
execute, is there a callback mechanism that chef uses while the run is
in progress, not after its completion as is the case with report
handlers? I want to be able to say to the user at one moment that “55
out of 1000 resources executed”.

I’m not aware of such a thing built into Chef, but one has to wonder
what the real value of that is if step 56 is going to take 2hrs, 57-83
will take 45 seconds, 84 will take 20 minutes, etc.


#5

Event handlers can do this.
On Aug 8, 2013 3:34 AM, “Lucian Ciufudean” lucian.ciufudean@gmail.com
wrote:

I might have not been clear.
Let’s say I start a chef run with 1k recipes and it will take 24h to
execute, is there a callback mechanism that chef uses while the run is in
progress, not after its completion as is the case with report handlers? I
want to be able to say to the user at one moment that “55 out of 1000
resources executed”.

Lucian

On Tue, Aug 6, 2013 at 2:29 PM, Mike miketheman@gmail.com wrote:

Take a look at this handler:
https://github.com/jamesc/chef-handler-elapsed-time
-M

On Tuesday, August 6, 2013, wrote:

Guys, is there a mechanism (maybe a chef handler trick) so that I can
report
(in a file for ex) the report of a long running chef run?

Cheers
Lucian


#6

It looks like event handlers can now hook into one of three places:

  • Start handlers hook in at the beginning of a run.
  • Report handlers hook in at the end of a successful run.
  • Exception handlers hook in after an exception is raised (i.e., after an
    unsuccessful run).

It seems to me that you’d need your code to fire at the beginning of a run
and monitor resources as they’re converged. So that’d be a start handler.
I don’t know of any start handlers in the wild (or within my organization)
… so I’m not sure how well-explored this area is in the community. Or
even if there’s any documentation on using them.

I suggest an alternative: Write your own Chef output formatter that
streams a progress update to a remote service.

Observe the behavior of the nyancat Chef formatter:

Just take out the nyancat bits and replace them with posting a JSON object
containing, perhaps, the run list being executed, start/end times of the
run, the number of resources being considered and the number of resources
processed and the final status of the run (success/fail).

If I had a Chef run that was taking 24 hours, I’d be looking at what was
taking so long and trying to break those steps out into a separate
orchestration tool, since I have a RunDeck server lying around that’s
pretty well-suited for scheduling and executing recurring batch jobs. Or,
to keep it in the Opscode family, I’d be clamoring to take some of those
long-running processes out of the “regular” Chef run and slot them into
some kind of recurring Pushy task.

On Thu, Aug 8, 2013 at 8:03 AM, Ranjib Dey dey.ranjib@gmail.com wrote:

Event handlers can do this.
On Aug 8, 2013 3:34 AM, “Lucian Ciufudean” lucian.ciufudean@gmail.com
wrote:

I might have not been clear.
Let’s say I start a chef run with 1k recipes and it will take 24h to
execute, is there a callback mechanism that chef uses while the run is in
progress, not after its completion as is the case with report handlers? I
want to be able to say to the user at one moment that “55 out of 1000
resources executed”.

Lucian

On Tue, Aug 6, 2013 at 2:29 PM, Mike miketheman@gmail.com wrote:

Take a look at this handler:
https://github.com/jamesc/chef-handler-elapsed-time
-M

On Tuesday, August 6, 2013, wrote:

Guys, is there a mechanism (maybe a chef handler trick) so that I can
report
(in a file for ex) the report of a long running chef run?

Cheers
Lucian


#7

i use it to get real time update, and also im working with another etcd
based handler for remote notifications (incomplete).

On Thu, Aug 8, 2013 at 11:33 AM, steve . leftathome@gmail.com wrote:

It looks like event handlers can now hook into one of three places:

  • Start handlers hook in at the beginning of a run.
  • Report handlers hook in at the end of a successful run.
  • Exception handlers hook in after an exception is raised (i.e., after an
    unsuccessful run).

It seems to me that you’d need your code to fire at the beginning of a run
and monitor resources as they’re converged. So that’d be a start handler.
I don’t know of any start handlers in the wild (or within my organization)
… so I’m not sure how well-explored this area is in the community. Or
even if there’s any documentation on using them.

I suggest an alternative: Write your own Chef output formatter that
streams a progress update to a remote service.

Observe the behavior of the nyancat Chef formatter:

https://github.com/andreacampi/nyan-cat-chef-formatter/blob/master/lib/nyan-cat-chef-formatter.rb

Just take out the nyancat bits and replace them with posting a JSON object
containing, perhaps, the run list being executed, start/end times of the
run, the number of resources being considered and the number of resources
processed and the final status of the run (success/fail).

If I had a Chef run that was taking 24 hours, I’d be looking at what was
taking so long and trying to break those steps out into a separate
orchestration tool, since I have a RunDeck server lying around that’s
pretty well-suited for scheduling and executing recurring batch jobs. Or,
to keep it in the Opscode family, I’d be clamoring to take some of those
long-running processes out of the “regular” Chef run and slot them into
some kind of recurring Pushy task.

On Thu, Aug 8, 2013 at 8:03 AM, Ranjib Dey dey.ranjib@gmail.com wrote:

Event handlers can do this.
On Aug 8, 2013 3:34 AM, “Lucian Ciufudean” lucian.ciufudean@gmail.com
wrote:

I might have not been clear.
Let’s say I start a chef run with 1k recipes and it will take 24h to
execute, is there a callback mechanism that chef uses while the run is in
progress, not after its completion as is the case with report handlers? I
want to be able to say to the user at one moment that “55 out of 1000
resources executed”.

Lucian

On Tue, Aug 6, 2013 at 2:29 PM, Mike miketheman@gmail.com wrote:

Take a look at this handler:
https://github.com/jamesc/chef-handler-elapsed-time
-M

On Tuesday, August 6, 2013, wrote:

Guys, is there a mechanism (maybe a chef handler trick) so that I can
report
(in a file for ex) the report of a long running chef run?

Cheers
Lucian


#8

On Thursday, August 8, 2013 at 11:33 AM, steve . wrote:

It looks like event handlers can now hook into one of three places:

  • Start handlers hook in at the beginning of a run.
  • Report handlers hook in at the end of a successful run.
  • Exception handlers hook in after an exception is raised (i.e., after an unsuccessful run).

It seems to me that you’d need your code to fire at the beginning of a run and monitor resources as they’re converged. So that’d be a start handler. I don’t know of any start handlers in the wild (or within my organization) … so I’m not sure how well-explored this area is in the community. Or even if there’s any documentation on using them.

I suggest an alternative: Write your own Chef output formatter that streams a progress update to a remote service.

Observe the behavior of the nyancat Chef formatter:
FWIW, Output formatters are built on a lower level instrumentation framework that we added in 10.14.0:

Configuration of custom event handlers is a little rough around the edges, this will improve as people start to use them and we understand the use cases better.


Daniel DeLeo


#9

That’s neat. I’m totally digging into that once I get through this
infinity of new product launches. We already have an internal metrics
dashboard that has a GUI mechanism for displaying Growl-like notifications
and I think it’s about to get progress bars for Chef runs! :smiley:

On Thu, Aug 8, 2013 at 11:52 AM, Daniel DeLeo dan@kallistec.com wrote:

On Thursday, August 8, 2013 at 11:33 AM, steve . wrote:

It looks like event handlers can now hook into one of three places:

  • Start handlers hook in at the beginning of a run.
  • Report handlers hook in at the end of a successful run.
  • Exception handlers hook in after an exception is raised (i.e., after an
    unsuccessful run).

It seems to me that you’d need your code to fire at the beginning of a run
and monitor resources as they’re converged. So that’d be a start handler.
I don’t know of any start handlers in the wild (or within my organization)
… so I’m not sure how well-explored this area is in the community. Or
even if there’s any documentation on using them.

I suggest an alternative: Write your own Chef output formatter that
streams a progress update to a remote service.

Observe the behavior of the nyancat Chef formatter:

FWIW, Output formatters are built on a lower level instrumentation
framework that we added in 10.14.0:

https://github.com/opscode/chef/blob/master/lib/chef/event_dispatch/base.rb

Configuration of custom event handlers is a little rough around the edges,
this will improve as people start to use them and we understand the use
cases better.


Daniel DeLeo