Backwards incompatible change to config.changed states

[Mark Shuttleworth]

I'd ask Cory to explore Merlijn's suggestions more deeply before we add
another state.

Mark

On 25/04/16 02:11, James Beedy wrote:
> 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/398d03df/attachment.html>