set_state not setting the state immediately

Mike Wilson mike.wilson at
Tue Oct 3 17:51:35 UTC 2017

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

On Tue, Oct 3, 2017 at 1:43 PM Alex Kavanagh <alex.kavanagh at>

> Hi there
> On Tue, Oct 3, 2017 at 1:34 PM, Konstantinos Tsakalozos <
> kos.tsakalozos at> 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
> Juju at
> Modify settings or unsubscribe at:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Juju mailing list