I sort of agree that it feels wrong to lump configuration change events into states. That said, adding another primitive doesn't seem like a good idea. The primitive doesn't nearly cover all cases. I think the problem with `x.changed` states is just a symptom, and we should address the root cause, not the symptoms.
*The root cause seems to me that there is no distinction between `states` and `events`.* A state such as `package.installed` is a fact. It will stay true until something manually removes the state. `config.changed` is not a state but an event. An event is only relevant at a single point in time, after that timepoint, the event gets removed. `file_changed` and `config_changed` are events that are only relevant in a single point of time. The reason that the `config_changed` event is relevant during an entire hook run is because hooks do not run in "real external time" but in an external timepoint. When an outside event happens during a hook run, the events get queued, and the next event is handled after the hook run is complete. A simple example is the stop hook; this can be seen as a `stop.requested` event. When a `config-changed` hook is running and an administrator destroys the service, the `stop` hook will only run after the `config-changed` hook is complete. Some advantages of introducing the concept of events: - It will be a lot clearer for devs that events get removed after a certain period of time and that states stay in the knowledgebase. Currently certain layers remove certain states at the start of a hook run; I think this can become very confusing for devs. - It would give us a clear 'logic' that tells us how to implement things like the 'file_changed' decorator. There are currently some issues with this: https://github.com/juju-solutions/charms.reactive/issues/44 - The connection between the reactive framework and the lifecycle(hooks) would be a lot clearer. Each hook is an external event; external events aren't processed in real-time; ... - This would pave the way for Charms to react to other events such as systemd dbus events as mgmt does: https://ttboj.wordpress.com/2016/01/18/next-generation-configuration-mgmt/. Imagine being able to run a hook when a systemd service crashes or when files change outside of a hook run! So, what do you think? This is hard to explain in a single email and I left a lot of the details out, so feel free to ask for more clarification! 2016-02-17 23:55 GMT+01:00 Matt Bruzek <[email protected]>: > 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 <[email protected]> > > On Wed, Feb 17, 2016 at 4:00 PM, Merlijn Sebrechts < > [email protected]> wrote: > >> Great! Very usefull! Thanks, Cory! >> >> >> Op woensdag 17 februari 2016 heeft Cory Johns <[email protected]> >> 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 >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> >> >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
