resolved always executes hooks

Was that an actual issue somehow?

It seems to me that this would be a nice default behavior. config-changed must necessarily be idempotent since it will be executed every time the configuration changes, which means reexecuting after a failure is a safe behavior.

I suggest we maintain this behavior, and reuse the same logic for all hooks we're sure are idempotent.

Excerpts from Gustavo Niemeyer's message of Sat Jul 23 21:15:41 UTC 2011:
> Was that an actual issue somehow?
>
> It seems to me that this would be a nice default behavior. config-
> changed must necessarily be idempotent since it will be executed every
> time the configuration changes, which means reexecuting after a failure
> is a safe behavior.
>
> I suggest we maintain this behavior, and reuse the same logic for all
> hooks we're sure are idempotent.

Yes, they should be idempotent, and I'd be in support of the default being
to retry, which I find myself almost always passing.

However, the only way to fix a broken config-changed hook with the
current behavior, without destroying the service, is:

* for each service unit
  * ssh in
    * manually change the config-changed hook so it will not error
  * run resolved
* upgrade-formula

So, for a sane way to fix broken formulas, we must either change the
default to match the draft doc here:

https://ensemble.ubuntu.com/docs/drafts/resolved.html

Which says

"After being resolved the unit would be in the started state. It important
to note that by default ensemble resolved does not fire hooks and the
start hook would not be invoked again as a result of the above."

*Or* change it, and provide a --no-retry. Or optionally, provide a
--ignore-error-state to upgrade-formula.

If I understand the issue correctly, the only thing that has to be changed is the draft doc so that it points out that
config-changed will retry by default because the hook is necessarily idempotent.

Excerpts from Gustavo Niemeyer's message of Mon Jul 25 17:43:07 UTC 2011:
> If I understand the issue correctly, the only thing that has to be changed is the draft doc so that it points out that
> config-changed will retry by default because the hook is necessarily idempotent.

Except that leaves us in a position where there is no way to fix a broken
hook except to destroy the service entirely, or go through the ssh and
manual intervention mess that I outlined before.

If the draft is changed, I'd suggest that a --no-retry must be added.

hmm.. there's some missing discussion here that wasn't captured on a solution for this in the upgrade scenario.

namely that we always execute config-changed after upgrade as well, afaicr, and we don't execute it when doing it without a retry.. and that we always execute it before starting.

it looks like this discussion went down a side track. but in examining it was clear there was a more obvious problem, resolved was executing hooks, effectively due to a typo, it was checking for the hook retry value as a boolean value, when it was an enumerated one.

oneiric has seen the end of its life and is no longer receiving any updates. Marking the oneiric task for this ticket as "Won't Fix".