On 18 February 2016 at 01:44, Cory Johns <[email protected]> wrote:
> If a charm config option has changed, the state "config.changed" will be set
> for the duration of the hook. Additionally, specific states will be set for
> each config option that changed; that is, if option "foo" has changed, the
> state "config.changed.foo" will be set. An example of code using this would
Will these states be set in the first hook?
I can come up with use cases for both yes and no answers to that
question. If I had done this in a layer, there would have been another
state named something like config.initial.
@when('config.changed')
def first_hook_and_config_changed(): pass
@when('config.changed')
@when_not('config.initial')
def config_changed_not_first_hook(): pass
> This provides a much cleaner way of detecting changes to config, and it is
> recommended that this be used in favor of @hook('config-changed') going
> forward, as the latter can actually run in to some situations, albeit rather
> rarely, where the charm sees new config option values before the
> config-changed hook has fired. Using the reactive states avoids that
> completely as well as working more naturally with existing @when decorators.
Did you want to pull in the Leadership layer too? Its hard to know
when to stop :) I'd thought this would be better handled as a layer,
for no other reason than it could be done as a separate layer and keep
the basic layer thin.
--
Stuart Bishop <[email protected]>
--
Juju mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
