[chef] Re: RE: Re: Re: Re: Monitoring chef runs

[Andrea Campi < >]

On Thu, Sep 6, 2012 at 5:25 PM, Christopher Brown 
<
 >
 wrote:
> There are a number of different considerations here, and it's worth teasing
> them all apart:
>
> 1) Do you want to know about impeding change, possibly without acting?  If
> so, check out "why run" in the latest builds:
> http://wiki.opscode.com/display/chef/Whyrun+Testing
> 2) Do you want to reduce the amount of change in a time period, thinking
> that's less likely to result in errors stacking up? (NOTE: that's not a
> provable claim, but an intuitive notion).  If so, either run chef-client
> from cron or as a daemon.
> 3) Do you want to *directly control* how and when change occurs?  If so, run
> chef-client manually.
> 4) Do you want to *directly control* how and when Ruby consumes memory?  If
> so, run chef-client manually.  Running any Ruby process as a daemon may
> result in a fair amount of memory being consumed / committed all the time.

And most of these options can be further automated using something
like mcollective.
We're looking into using it to add some "push" capabilities for
on-demand changes.

Andrea