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

[Daniel DeLeo < >]

On Friday, September 7, 2012 at 3:06 PM, KC Braunschweig wrote:

On Thu, Sep 6, 2012 at 8:26 AM, Tetsu Soh < "> > wrote:

One more thing need your attention, exception handler can only handle

runtime exception but not compile time exception.

If your recipe broke on compile time, the chef-client will stop without

running and exception handler.

Would people consider this a bug? I (unfortunately) do a lot at

compile-time so dying there is fairly likely and I'd really like to

know about that too. Anyone have a good workaround? Would it be

appropriate to always run exception handlers? Or should there be an

alternate mechanism for compile-time failures?

A couple related points:

- I noticed (probably for the same reason) that when runs die early

you don't get the run duration, which I'd still like to have.

- I've run into this scenario a lot:

1. Run updates resource X

2. resource X notifies a restart of service Xd (delay)

3. An exception happens on resource Y and the chef run dies before

delayed notifications are processed. At this point service Xd hasn't

been restarted which is probably good because that might cause a bad

state since the run failed.

4. I come along to troubleshoot, fix things and run chef again

5. chef run (including resource Y) now completes successfully but

the restart of service Xd never happened. Now I have a system that

seems like it should be in a good state but it might not be because

service Xd still has old config in memory and I have no way to know

that and chef will never fix it.

Anyone have a good way to prevent or address the above?

Thanks,

KC

There's a patch where delayed notifications are always run in master. This is a pretty significant behavior change so we're waiting until Chef 11 to ship it.

-- 

Daniel DeLeo