- From: Kannan Manickam <
>
- To: Dan Razzell <
>
- Cc:
- Subject: [chef] Re: A proof of concept cookbook for the on_failure Chef RFC
- Date: Wed, 9 Apr 2014 13:10:44 -0700
Hello Dan,
Thanks for your ideas.
My responses are inline.
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.
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:
" type="cite">
|
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
Archive powered by MHonArc 2.6.16.