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