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

[Lamont Granquist < >]

On 9/6/12 1:20 PM, KC Braunschweig wrote:
> - Another reason to keep chef running all the time is that you're less 
> likely to fight with it. If it takes minimum 24 hours to push a change 
> with chef (example above) and you need to do something faster (OMG 
> prod is on fire!), you're not going to use chef, you're going to do 
> something else (ssh for loop?). Maybe you'll remember to backport your 
> change into chef. Maybe when you backport it into chef it'll actually 
> come out compatible rather than just slightly not the same. Maybe not, 
> and every time that fails everyone who doesn't know better blames chef 
> for undoing their productive work. Now they're working against the 
> tool instead of the tool making their lives better. KC 
Or just:

knife ssh '*:*' sudo chef-client

To force a push in an emergency, or if you have changes that must be 
rolled out in a given window and can't be done lazily.  I used lazy 
overnight config rollouts at one job, but at others I've had to fit all 
of the change within a given window; so while I've still used 24h 
cronjobs for periodic convergence, I've used knife ssh to kick off 
changes across the whole fleet at once.