On 28 January 2016 at 21:42, Cory Johns <cory.jo...@canonical.com> wrote:
> I also very much like the pattern of having states that notify of changes to
> the leadership settings and think this pattern could apply well to config
> settings. One addition I would suggest to that pattern would be to also
On config, yes, a similar pattern could be applied. It is somewhat
more complex than leadership though. The three different states I'm
thinking of are:
- config.set.{name}. The configuration option 'name' exists and is set
to a value. It is not set to null or the empty string.
- config.default.{name}. The configuration option 'name' exists, and
its value is unchanged from the default defined in config.yaml.
- config.changed.{name}. The configuration option 'name' exists and
its value has been changed since the previous hook was run. This state
will not be set in the next hook, unless the configuration option was
changed yet again.
(The wording specifically mentions the options existing, to be
specific about what will happen in upgrade-charm when config options
are dropped and no longer exist)
The very first hook invoked (be it the install hook or a storage hook)
will have interesting behaviour. What options get the
config.changed.{name} state set? None of them? All of them? All that
have values changed from the default? I'm unsure of the best answer,
which is why the layer doesn't exist yet :) Should handlers waiting on
the config.changed.foo state always be invoked in the first hook,
never invoked in the first hook, or possibly be invoked in the first
hook?
> have a blanket `leadership.changed` state that would be set when *any* value
> was changed. This is mostly to handle the case where you need to react to
> any of a set of multiple values changing. Thoughts?
I've added this.
--
Stuart Bishop <stuart.bis...@canonical.com>
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
