[chef] Re: A proof of concept cookbook for the on_failure Chef RFC

[Dan Razzell < >]

On 14-04-09 01:10 PM, Kannan Manickam wrote:

" type="cite"> Hello Dan,

Thanks for your ideas.

My responses are inline.

Ditto.

" type="cite">

On Apr 9, 2014, at 12:12 PM, Dan Razzell < "> > wrote:

Nice.  A processing path for resource failures has been conspicuously absent in Chef, and workarounds require painfully awkward management of success counters.

I appreciate that, in keeping with the spirit of convergence, the on_failure attribute is designed to retry the original resource once its block completes.  But there's another, lower level use case that more closely resembles notification, only for failure.  Indeed it would be best implemented as an :on_failure option for the notifies and subscribes attributes.

That is one way to do it but that limits on what we can do during the failure. This implementation can contain arbitrary ruby code. Let’s see what others think.

My intention here was not to suggest changes to your proposal at all, instead I wanted to point out a similar treatment for notifies and subscribes, thinking that perhaps this is the most natural way to express the case when control should not return to the original resource.

" type="cite">

That discussion would be somewhat out of scope for the on_failure RFC, except that a very similar effect could be had if on_failure supported something like a noretry option.  It would be clear from this option that the original resource was not to be retried on completion of the specified block.  Control would return to the resource, however, so that in the ordinary way, depending on the value for ignore_failure, it would either continue the recipe or raise an exception.

I was also thinking about something like this. There might be cases where you want to make sure some steps are done before the Chef run fails.

That's definitely a use case.  My particular interest is somewhat different.  The entire Chef run has to carry on to try an alternate resource if the first one fails.  Since the cases that I'm working on involve dozens or hundreds of such resources, it's important for the notation to be compact and easy to follow, which it currently is not because Chef doesn't provide a means to dispatch on failure.  Independent of this, there's often a need for a modest amount of tabulation during resource processing for later report generation.  Whether a particular resource succeeds or fails, we still want to report its data.