Thank you both. It is clear now. On Fri, Nov 10, 2017 at 6:14 PM, Stuart Bishop <[email protected]> wrote: > 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
