I hate to go against the love-in here. While I desperately want a
configuration changed feature for the reactive framework. I disagree with
the way it was implemented. I brought up issues with this implementation in
the pull request: https://github.com/juju-solutions/layer-basic/pull/36
It feels wrong to lump configuration change events in to states. There
should be a different way to handle these types of events that are
generated by Juju. We already have @hook('config-changed') for when the
traditional hook would be called. When a configuration changes it would be
more natural should have a different decorator for that such as:
@when_changed('key') or more importantly
@when_any_changed('key1','key2','key3')
Charm states are completely arbitrary and an author (who may not read this
list) could legitimately set a 'config.changed' state that would create
invalid changed events and break other layers. Even if we pick a different
state name it seems we are inviting a possible collision that would be very
difficult to diagnose and debug.
It feels strange that we are "reserving" a state name (or many names) for
the configuration changes in this way. Implementing the feature with a
different decorator seems more deterministic and not overloading the states
with configuration events.
Thoughts?
- Matt Bruzek <matthew.bru...@canonical.com>
On Wed, Feb 17, 2016 at 4:00 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:
> Great! Very usefull! Thanks, Cory!
>
>
> Op woensdag 17 februari 2016 heeft Cory Johns <cory.jo...@canonical.com>
> het volgende geschreven:
> > Just wanted to give a heads-up about a feature that landed in the
> reactive base layer yesterday.
> > 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 be:
> > @when('myservice.started', 'config.changed')
> > def update_config():
> > update_config_files()
> > restart_myservice()
> > 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.
> > Please note that, while we are not aware of any charms currently using
> "config.changed" as a state, there is some risk of the state set by the
> base layer conflicting with it if set by the charm layer. The
> recommendation is to always prefix your states by the name of the layer
> setting them, or the relation name for interface layers.
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
