I think that's another nail in the coffin for @hook. You could work around
it by having your @hook('upgrade-charm') handler unconditionally set a
state (e.g., 'upgrade-charm'), and then have the state handler do the
gating on leadership. This would also allow you to use the decorators for
gating on leadership.is_leader, rather than using the is_leader() function.
I definitely want to move toward having the reactive framework itself
manage states like upgrade-charm, and {relation_name}.joined so that we can
remove all uses of @hook.
On Wed, Dec 14, 2016 at 6:00 AM, Stuart Bishop <stuart.bis...@canonical.com>
wrote:
>
>
> On 14 December 2016 at 00:39, Matthew Williams <
> matthew.willi...@canonical.com> wrote:
>
>> Hey Folks,
>>
>> Let's say I'm a charm author that wants to test leadership election in my
>> charm. Are there any tools available that will let me force leadership
>> election in juju so that I can test how my charm handles it? I was looking
>> at the docs here: https://jujucharms.com/docs/stable/developer-leadership
>> but couldn't see anything
>>
>
> I don't think there is any supported way of doing this.
>
> If you don't mind an unsupported hack though, use 'juju ssh' to shut down
> the unit's jujud, wait 30 seconds for the lease to expire, and you should
> have a new leader. 'juju ssh' again to restart the jujud, 'juju wait' for
> the hooks to clear, and failover is done. 'juju run' will hang if you use
> it to shutdown jujud, so don't do that.
>
> juju ssh ubuntu/0 'sudo systemctl stop jujud-unit-ubuntu-0.service'
> sleep 30
> juju ssh ubuntu/0 'sudo systemctl stop jujud-unit-ubuntu-0.service'
> juju wait
>
> Ideally, you may be able to structure things so that it doesn't matter
> which unit is leader. If all state relating to leadership decisions is
> stored in the leadership settings, and if you avoid using @hook, then it
> doesn't matter which unit makes the decisions. Worst case is that *no* unit
> is leader when hooks are run, and decisions get deferred until
> leader-elected runs.
>
> (Interesting race condition for the day: It is possible for all units in a
> service to run their upgrade-charm hook and for none of them to be leader
> at the time, so @hook('upgrade-charm') code guarded by is-leader may never
> run. And reactive handlers have no concept of priority and might kick in
> rather late for upgrade steps, requiring more creative use of reactive
> states to guard 'new' code from running too soon. Not specific to
> upgrade-charm hooks either, so avoid using @hook and leadership together)
>
>
> --
> Stuart Bishop <stuart.bis...@canonical.com>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
