So the best practice here is to touch a file and test for the existence of
that file before running must_be_called_exactly_once()?

I think part of the issue here is that without knowing the extent of the
hook it is hard to enforce idempotency as a charm writer. It's easy to look
at the code above and say that is it idempotent since the init function is
wrapped in a when_not and the initialized state is set at the bottom of
init.

On Tue, Oct 3, 2017 at 1:43 PM Alex Kavanagh <[email protected]>
wrote:

> Hi there
>
>
>
> On Tue, Oct 3, 2017 at 1:34 PM, Konstantinos Tsakalozos <
> [email protected]> wrote:
>
>> Hi,
>>
>> It seems the reactive framework is flushing the states at the end of hook
>> execution. This may surprise charm authors. Consider the following code:
>>
>> @when_not("initialized")
>> def init():
>>     must_be_called_exactly_once()
>>     set_state("initialized")
>>
>> @when("initialized")
>> @when_not("ready")
>> def get_ready():
>>     this_call_fails()
>>     set_state("ready")
>>
>> As a charm author I would expect the "initialized" state set right after
>> the must_be_called_exactly_once() is called. However, the framework is not
>> persisting the "initialized" state at that point, and it moves on to
>> trigger the get_ready(). Since this_call_fails() happens on
>> the  get_ready() method I would expect the "initialized" state to be set
>> when the failure is resolved.
>>
>>
> Yup, that can catch you out.  As Stuart says, it's because either a hook
> competes 'fully' or not at all, and so it rolls back (or rather doesn't
> commit) the kv() store.  So anything you put in kv() (from
> charmhelpers.core.unitdata) also won't get committed.   Also, if you flush
> kv() yourself you'll mess with charms.reactive.
>
> In this situation, I tend to use a file as a sentinel to flag that I've
> really done something only once.  Alternatively, one could use
> charmhelpers.core.unitdata.Storage() directly and thus flush a separate
> Storage() back to the 'disk'.
>
>
>
> --
> Alex Kavanagh - Software Engineer
> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
> --
> 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

Reply via email to