Is a set state called multiple times?
fengxia
fxia1 at lenovo.com
Thu Jul 27 20:09:38 UTC 2017
Now thinking of it, I just realized that this concept of True state
executing repeatedly is actually a good thing.
In many cases, there is a need to query external resource for its
status. This is often implemented as a polling loop. So in charm, I can
implement it as
@when("prep")
def prep():
# are we there yet?
is_ready = prep_test()
if is_ready:
remove_state("prep")
set_state("do.sth")
@when("do.sth")
def do_sth():
# do this
pass
# move on
remove_state("do.sth")
set_state("next")
On 07/27/2017 03:56 PM, Cory Johns wrote:
> fengxia,
>
> It's probably more enlightening to think of them as "flags" rather
> than states. (Indeed, the next release of charms.reactive will
> deprecate calling them states and will provide set_flag, remove_flag,
> etc. functions instead.)
>
> On Thu, Jul 27, 2017 at 3:29 PM, fengxia <fxia1 at lenovo.com
> <mailto:fxia1 at lenovo.com>> wrote:
>
> Alex,
>
> Thank you for the detailed explanations and examples.
>
> After reading Tilman's and Cory's replies, I think the confusion
> is at continuous evaluation (thus execution) of a True state. So a
> pair of @when and @when_not will result in one of them being
> executed over and over despite adding a remove_state("myself") in
> the @when block.
>
> I'm still trying to grasp the idea of this "state" instead of
> treating it as an event handler.
>
> So for states, I usually draw a state machine diagram. In this
> case, it feels rather unnatural that all True states will
> inherently loop to themselves.
>
> But I don't what alternative is in charm's context.
>
>
> On 07/27/2017 04:13 AM, Alex Kavanagh wrote:
>> Hi
>>
>> On Thu, Jul 27, 2017 at 2:37 AM, fengxia <fxia1 at lenovo.com
>> <mailto:fxia1 at lenovo.com>> wrote:
>>
>> Hi Juju,
>>
>> Once I set a state, set_state("here"), I want to make sure
>> its @when will only be executed ONCE (when "here" from
>> False->True).
>>
>> So my thought is to remove_state("here") in its @when("here")
>> code block. If I don't, will this @when be called multiple
>> times if I don't reset this state? What's the good practice here?
>>
>>
>> You have a couple of options here depending on the nature of the
>> handler.
>>
>> 1. If, in the lifetime of the unit's existence, the handler only
>> has to execute ONCE. (and I mean EVER), then there is a
>> @only_once decorator that can be used. It can be used in
>> combination with other decorators to set up a condition, but
>> it guarantees that the handler will only be called once.
>> However, what you probably want is ...
>> 2. Use a @when_not('flag') and then set it the 'flag' in the
>> body of the handler.
>>
>> The first would look something like:
>>
>> @when('some-condition-flag')
>> @only_once
>> def
>> do_something_only_once_when_some_condition_flag_is_set_for_the_first_time():
>> ... do something once ...
>>
>> The second treats a flag as a 'have I done this yet' condition,
>> and allows you to reset the flag at some other point in the
>> charm's life cycle so that you can do it again. 'installed' is a
>> good example of this:
>>
>> @when_not('installed-something')
>> def do_install_of_something():
>> ... do the installation ...
>> # when it is fully successful, set the installed-something
>> flag. Don't set it early as
>> # if it errors, a future handler invocation may be able to
>> continue the installation.
>> set_state('installed-something')
>>
>>
>> @when(some other conditions indicating do an upgrade)
>> def do_upgrade():
>> ... set upgrade sources, or other pre upgrade actions
>> remove_state('installed-something')
>>
>> In this situation, hopefully you can see that we can re-use
>> 'do_install_of_something()' when we do upgrades.
>>
>> I think it's useful to think about states (flags) as being a
>> 'memory' that something has happened, and use them to either gate
>> on not doing things again, or to trigger the next action is a
>> graph of actions that need to take place to get the charm's
>> payload to the desired operational state. I tend to name them,
>> and use them, to indicate when something has happened, rather
>> than when it hasn't, and so tend to use @when_not('some-flag') on
>> the handler that eventually sets that flag.
>>
>> Hope that this helps.
>> Alex.
>>
>>
>>
>> --
>> Feng xia
>> Engineer
>> Lenovo USA
>>
>> Phone: 5088011794 <tel:5088011794>
>> fxia1 at lenovo.com <mailto:fxia1 at lenovo.com>
>>
>> Lenovo.com
>> Twitter | Facebook | Instagram | Blogs | Forums
>>
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com <mailto:Juju at lists.ubuntu.com>
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>> <https://lists.ubuntu.com/mailman/listinfo/juju>
>>
>>
>>
>>
>> --
>> Alex Kavanagh - Software Engineer
>> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone:5088011794 <tel:%28508%29%20801-1794>
> fxia1 at lenovo.com <mailto:fxia1 at lenovo.com>
>
> Lenovo.com
> Twitter | Facebook | Instagram | Blogs | Forums
>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com <mailto:Juju at lists.ubuntu.com>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
> <https://lists.ubuntu.com/mailman/listinfo/juju>
>
>
>
>
--
Feng xia
Engineer
Lenovo USA
Phone: 5088011794
fxia1 at lenovo.com
Lenovo.com
Twitter | Facebook | Instagram | Blogs | Forums
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170727/bee93a3a/attachment.html>
More information about the Juju
mailing list