Hook firing

Simon Davy bloodearnest at gmail.com
Wed Sep 3 14:38:36 UTC 2014

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

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.



More information about the Juju mailing list