A proof of concept cookbook for the on_failure Chef RFC


#1

[image: Ohai Chefs!]

I have playing with a proof of concept cookbook for the on_failure
Chef RFChttps://github.com/opscode/chef-rfc/blob/sethvargo/on_failure/on_failure.mdproposed
recently. I made some good progress on that and it works for most
use cases. So I just wanted to share it with everybody.

Here is the: https://github.com/arangamani-cookbooks/on_failure
I published it to the community site:
http://community.opscode.com/cookbooks/on_failure

And I wrote the following blog post that explains how this works including
some demonstration.
http://blog.arangamani.net/blog/2014/04/08/chef-on-failure-handler/

Thanks Steven, Paul, and Seth for providing awesome examples in the
RFChttps://github.com/opscode/chef-rfc/blob/sethvargo/on_failure/on_failure.md
.

Cheers,
Kannan.


#2

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 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.

Thanks,
Dan

On 14-04-09 12:37 AM, Kannan Manickam wrote:

Ohai Chefs!

I have playing with a proof of concept cookbook for the on_failure
Chef RFC
https://github.com/opscode/chef-rfc/blob/sethvargo/on_failure/on_failure.md
proposed recently. I made some good progress on that and it works for
most use cases. So I just wanted to share it with everybody.

Here is the: https://github.com/arangamani-cookbooks/on_failure
I published it to the community site:
http://community.opscode.com/cookbooks/on_failure

And I wrote the following blog post that explains how this works
including some demonstration.
http://blog.arangamani.net/blog/2014/04/08/chef-on-failure-handler/

Thanks Steven, Paul, and Seth for providing awesome examples in the
RFC
https://github.com/opscode/chef-rfc/blob/sethvargo/on_failure/on_failure.md.

Cheers,
Kannan.


#3

Hello Dan,

Thanks for your ideas.

My responses are inline.

On Apr 9, 2014, at 12:12 PM, Dan Razzell danr@activestate.com 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.

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. I currently use a Chef handler for this and wrote a blog post here: http://blog.arangamani.net/blog/2014/03/30/writing-custom-chef-handlers/. So the noretry option would simply execute the block and raise the original exception.

Thanks,
Dan

On 14-04-09 12:37 AM, Kannan Manickam wrote:

I have playing with a proof of concept cookbook for the on_failure Chef RFC proposed recently. I made some good progress on that and it works for most use cases. So I just wanted to share it with everybody.

Here is the: https://github.com/arangamani-cookbooks/on_failure
I published it to the community site: http://community.opscode.com/cookbooks/on_failure

And I wrote the following blog post that explains how this works including some demonstration.
http://blog.arangamani.net/blog/2014/04/08/chef-on-failure-handler/

Thanks Steven, Paul, and Seth for providing awesome examples in the RFC.

Cheers,
Kannan.


#4

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

Hello Dan,

Thanks for your ideas.

My responses are inline.

Ditto.

On Apr 9, 2014, at 12:12 PM, Dan Razzell <danr@activestate.com
mailto:danr@activestate.com> 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.

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.