Hook firing

John Meinel john at arbash-meinel.com
Wed Sep 3 14:54:25 UTC 2014

Given CAP theorem any message can really only be "at most once" or "at
least once". You can never guarantee "exactly only once".
I'm sure juju is biased to the "at least once" for hooks (hence why it runs
at agent restart because it hasn't been around to know for sure that
nothing changed in the interim).
So while there could be a bug, hooks should be written with a design that
they may get called more than once for the same state. (At most once would
mean that changes could occur that you never see, which is usually a far
worse failure mode.)

On Sep 3, 2014 6:39 PM, "Simon Davy" <bloodearnest at gmail.com> wrote:

> Arg, resending reply to list
> On 3 September 2014 14:27, José Antonio Rey <jose at ubuntu.com> wrote:
> > Even if the config-changed hook was run when it was not supposed to, it
> > shouldn't have caused any changed if values were not moved to anything
> > different. If it did, then I believe we're having an idempotency problem
> > there.
> I suspect this has been happening for a while, but unnoticed, as most
> case the hook will run fine.
> In our cases, an implementation issue with tokens that expire after a
> fixed period of 24hr were being reused (to fetch build assets from
> swift), so we noticed the run as it tripped an error state, which we
> have nagios alerts for. We are fixing our charms to not have this
> problem.
> But we raised the questions for 2 reasons:
> 1) We want to understand why it's happening. Its probably ok that it
> does happen, but it's the apparent randomness that is confusing.
> 2) If a charm has relied on juju's idempotency provisions exclusively,
> then a config-changed hook's implementation may *always* restart
> whatever server process the charm is managing even though nothing has
> actually changed (we specifically avoid this in our charms where
> possible). This could lead to unnecessary service wide restarts, which
> is undesirable in many circumstances, especially with no current way
> to control those.
> So yeah, we'd like to get to the bottom of the cause for 1), for our
> own understand the system, but perhaps 2) needs some consideration
> from juju-core.
> Thanks
> --
> Simon
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20140903/59ca525b/attachment.html>

More information about the Juju mailing list