Backwards incompatible change to config.changed states

[James Beedy]

I think this is an excellent idea! The the initial setting of the
config.changed hook has caused contention in charm design and
implementation for me. Not having to account for the config.changed hooks
firing, when logically it seems that one shouldn't have to (e.g. no configs
have changed yet), would probably ease uptake for new-comers who aren't
familiar with the intrinsics of why a config.changed hook fires without
configs changing. I think Cory's implementation is a non-intrusive way of
handling this issue whilst also providing backwards compatibility for the
legacy functionality.

> I have proposed https://github.com/juju-solutions/layer-basic/pull/61 as a
> slight change to how the config.changed states from the basic layer work.
> Currently, the changed states are set during the first hook invocation,
> under the assumption that the values were "changed" from "nothing" (not
> being set at all).  However, this is slightly problematic in a case like
> the following, where we expect install() to  only be called once, unless
> the value has changed after the fact:
>
> @when_not('installed')def install():
>     # do install
>     set_state('installed')
> @when('config.changed.install_source')def reinstall():
>     install()
>
>
> The proposal adds new states, config.new, and changes config.changed to
not
> be set the first time.  You could get the old behavior by saying
> @when_any('config.new.foo', 'config.changed.foo').
>
> Is anyone depending on the current behavior?  Are there any objections to
> this change?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160425/9e778fd1/attachment.html>