Arg, resending reply to list On 3 September 2014 14:27, José Antonio Rey <[email protected]> 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 [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
