set_state not setting the state immediately

[Alex Kavanagh]

Hi there



On Tue, Oct 3, 2017 at 1:34 PM, Konstantinos Tsakalozos <
kos.tsakalozos at canonical.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20171003/5b92f057/attachment.html>