set_state not setting the state immediately

[Konstantinos Tsakalozos]

Thank you both. It is clear now.

On Fri, Nov 10, 2017 at 6:14 PM, Stuart Bishop
<stuart.bishop at canonical.com> wrote:
> On 10 November 2017 at 21:54, Konstantinos Tsakalozos
> <kos.tsakalozos at canonical.com> wrote:
>
>> Even if it is not correct, the behaviour of the bash reactive is what
>> the naive ( :) ) developer expects. Can you give me a concrete example
>> of what can go wrong with the approach the bash reactive
>> implementation is taking? Stuart, you mention "changes made to the
>> Juju environment get rolled back on hook failure" could some of these
>> changes cause a bash reactive charm to misbehave, can you please give
>> me an example?
>
> Here is a trivial handler that informs the unit's peers that it is
> available. If the hook fails, but the state persists, the peers are
> never informed. Some information has persisted (the charms.reactive
> state), and other information has been thrown away (the Juju
> environment state).
>
> @when('mycharm.configured')
> @when_not('mycharm.joined')
> def join():
>     for relid in relation_ids('cluster'):
>         relation_set(relid, active='true')
>     set_state('mycharm.joined')
>
> Here is a common one you may have written yourself, where the
> configured port  might never be opened:
>
> @when('config.changed.port')
> def open_port():
>      prev_port = unitdata.kv().get('mycharm.port')
>      new_port = config()['port']
>      if prev_port is not None:
>          close_port(prev_port)
>      open_port(new_port)
>      unitdata.kv().set('mycharm.port', new_port)
>
> --
> Stuart Bishop <stuart.bishop at canonical.com>