Progress of a chef run

Lucian_Ciufudean · August 6, 2013, 10:38am

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

Mike · August 6, 2013, 11:29am

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

Lucian_Ciufudean · August 8, 2013, 10:33am

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:
GitHub - jamesc/chef-handler-elapsed-time: A chef handler that reports on per-resource elasped times in a simple graphical form
-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

Jeff_Blaine · August 8, 2013, 1:19pm

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.

Ranjib · August 8, 2013, 3:03pm

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:
GitHub - jamesc/chef-handler-elapsed-time: A chef handler that reports on per-resource elasped times in a simple graphical form
-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

steve · August 8, 2013, 6:33pm

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:

github.com

andreacampi/nyan-cat-chef-formatter/blob/master/lib/nyan-cat-chef-formatter.rb

require 'chef/formatters/minimal'

class Chef
  module Formatters
    class NyanCat < Formatters::Minimal

      cli_name(:nyan)

      ESC      = "\e["
      NND      = "#{ESC}0m"
      PASS     = '='
      PASS_ARY = ['-', '_']
      FAIL     = '*'
      ERROR    = '!'
      UPDATED  = '+'

      # attr_reader :current, :example_results, :color_index, :pending_count,
      #             :failure_count, :example_count
      # 
      def initialize(out, err)

This file has been truncated. show original

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:
GitHub - jamesc/chef-handler-elapsed-time: A chef handler that reports on per-resource elasped times in a simple graphical form
-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

Ranjib · August 8, 2013, 6:36pm

gist.github.com

https://gist.github.com/ranjib/5960964

README.md

Chef 11 introduces event dispatching mechanism, which emits event at different milestones in Chef run (aka lifecycle) , and users can add their custom handlers to hook into these events. Chef formatters already uses this API. For a complete list of currently available events check [this](https://github.com/opscode/chef/blob/master/lib/chef/event_dispatch/base.rb)

Following is a bare minimal example for adding a custom handler:

### chef_event_handler_foo.rb
```ruby
require 'chef/event_dispatch/base'
class Foo < Chef::EventDispatch::Base
  # lets say hello world when chef run ends
  def run_completed(node)

This file has been truncated. show original

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:
GitHub - jamesc/chef-handler-elapsed-time: A chef handler that reports on per-resource elasped times in a simple graphical form
-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

kallistec · August 8, 2013, 6:52pm

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:

github.com

chef/chef/blob/main/lib/chef/event_dispatch/base.rb

class Chef

  # ==EventDispatch
  # Classes in EventDispatch deal with collecting, distributing, and handling
  # information in response to events that occur during a chef-client run.
  #
  # EventDispatch uses a simple publishing system where data from all events
  # are forwarded to all subscribers unconditionally.
  #
  # EventDispatch is used to implement custom console output formatters so that
  # users may have more control over the formatting and verbosity of Chef
  # client output and client-side data collection for server-side client
  # history storage and reporting.
  #
  # === API Stability Status
  # The EventDispatch API is intended to become a stable, public API upon which
  # end-users can implement their own custom output formatters, reporting
  # integration libraries, and more. This is a new feature, however, so
  # breaking changes may be required as it "bakes" in order to provide a clean,
  # coherent and supportable API in the long term. Therefore, developers should

This file has been truncated. show original

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

steve · August 8, 2013, 7:47pm

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!

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

Topic		Replies	Views
Chef v11 opensource - recipe timing data Chef Infra (archive)	2	794	December 29, 2015
Handlers run multiple times since chef 13 upgrade Chef Infra (archive)	0	460	November 28, 2017
Poor man's reporting Chef Infra (archive)	4	388	August 18, 2014
Chef Manage WebUI Not Reporting Finished Runs Chef Infra (archive)	1	264	April 7, 2014
How to know chef-client run start and end time Chef Infra (archive)	3	2670	May 7, 2014

Progress of a chef run

Related topics