[chef] Re: Re: Delayed actions don't run if a recipe fails

[Dan DeMaggio < >]

On Mon, Nov 22, 2010 at 10:13 PM, Daniel DeLeo 
<
 >
 wrote:
> It's a tough situation, services are unique in that they have state
> in-memory that's difficult/impossible for chef to query (unless you
> somehow instrument your services).

Instead of thinking of the service, think about logging Chef's
intentions in an idempotent way:

1) For each file change (that has a notification), Chen can create an
INTENTION file (or append a line in a file). The intention file simply
has the filename, and the new MD5.
2) when the associated notification is delivered, we delete that file
(or that line in the file).
3) At the end of a successful run, we can delete all intention files/entries.

Now, when a file is *not* changed, we consult the intention DB. if it
has our file+MD5, we pretend the file was just changed. This sets up
the delayed notification again. If we fail again, we continue to think
that "the file is still new if it has this MD5".

Note that:
- if the recipe isn't run, this feature is ignored (we won't see our
file + md5, so we won't trigger. At the end of the run we forget about
it)
- if the file changes _again_, we won't trigger (will have a different
MD5, which will only trigger the normal change notification)
- if the recipe changes (add/remove notifications) we will trigger
whatever the new recipe says
- Things get a little tricky if one file notifies multiple services.
We could *not* do notifications in this case, and we'd be no worse
off. (i.e. we'd be fixing the single-notification case, and leaving
the multi-notification case broken as it is now.)


-=Dan=-