On 10 November 2017 at 21:54, Konstantinos Tsakalozos
<[email protected]> 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 <[email protected]>
--
Juju mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
