Tim,One (really hacky, some might even say kludgy) way to accomplish what
you want, at least for reporting of failed runs via email, would be to
include a Ruby at_exit hook in a recipe. Note that this is only effective
if you run the client via cron or some mechanism where the chef-client
program exits–so anything using the interval (-i) option won’t work with
this hack. Here’s some code that demonstrates the various behaviors you can
see with at_exit
raise “an uncaught error”
don’t need to do anything
raise "an error that will be rescued"
rescue => e
# don't need to do anything
In the code above, $! is the last “unrescued” error raised. I didn’t have a
chance to see what the results are when using this in a chef run, so you’ll
need to do additional research on your own, but from what I can tell you’ll
have these cases:
- for a successful run, you’ll have !.kind_of?(SystemExit) #=> true and
!.success? #=> true
- Chef might kill itself due to a configuration problem or something, in
this case you’ll probably see !.kind_of?(SystemExit) #=> true and
!.success #=> false
- for a run that dies due to an error being raised in a recipe, you should
that error in !, i.e., !.kind_of?(SystemExit) #=> false
Hope this helps,
On Thu, Oct 22, 2009 at 10:27 AM, Nick Ohanian email@example.com wrote:
I second this. I had the same need, and I ended up rolling my own scripts
to do this. Otherwise there is no visibility into what’s “really” going on
in the deployment. However, while this is certainly an important part of
"managing your servers", it might be outside of the scope of Chef’s goals.
Chef is good at “configuring your servers”, but is it the intent of Chef to
(eventually) provide support for “monitoring your servers”?
Tim Uckun wrote:
Is there a way to wrap some code around the chef run?
I have two specific goals.
- Catch exceptions and email them to me.
- Send some data to my monitoring service after the run (if nothing
else just the fact that the run took place and went OK but I would
like to include other data from ohai).