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.
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.
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.
Our use case is slightly different.
We would need a solution for
resource1
if fails, notifies resource2, but don't return
resource2
if fails, throw error (standard behaviour)
It seems setting on_failure(retries: 0) does not do this.
What best way to implement this (keeping originally intended behaviour available, as it might be used later)