- From: "steve ." <
>
- To: "
" <
>
- Subject: [chef] Re: Re: Re: Re: progress of a chef run
- Date: Thu, 8 Aug 2013 11:33:32 -0700
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.
Archive powered by MHonArc 2.6.16.