leader-elected event is emitted for a unit that is elected as leader. A unit receiving it can be guaranteed that it will have leadership for approximately 30 seconds (from the moment the event is received). After that time, juju might have elected a different leader.
Leadership can change while a hook is running. (you could start a hook on unit/0 who is the leader, and while that hook is processing, you lose network connectivity for a long time [more than 30s], and then by the time the hook notices, juju has already moved on to another leader.)
Juju doesn’t guarantee that a leader will see every event: if the leader unit is overloaded long enough for the lease to expire, then juju will elect a different leader. Events that fired in between would be received units that are not leader yet or not leader anymore.
leader-electedis always emitted after peer-
relation-created. However, by the time
relation-createdruns, juju may already have a leader.
- charms that flip into an error state will attempt to re-run the event that caused the error when a human operator runs “juju resolve” on the charm.
- When a leader loses leadership it only sees the
leader-settings-changedevent, just like all the other non-leader units. Therefore,
leader-electedis only ever received if right now, you are the leader.
- On scale-down, if the leader was one of the units removed, then one of the remaining units will be elected as leader and see the
leader-electedevent; all the other remaining units will see
This section is about how to ‘cause’ this event.
It is not possible to select a specific unit and ‘promote’ that unit to leader, or ‘demote’ an existing leader unit. Juju has control over which unit will become leader after the current leader is gone.
However, you can cause leadership change by destroying the leader unit or killing the jujud-machine service in operator charms.
- non-k8s models:
juju remove-unit <leader_unit>
- operator charms:
juju ssh -m <id> -- systemctl stop jujud-machine-<id>
- sidecar charms: ssh into the charm container, source the
/etc/profile.d/juju-introspection.shscript, and then get access to a whole bunch of helpful shell functions, including
That will cause the lease to expire inside 60s, and another unit of the same application will be elected leader and receive
Disclaimer: see juju/1958542 for a known bug with this.
It is also possible to cause leadership change ‘indirectly’, by scaling down an application. Typically if you deploy multiple units from the start (e.g.
juju deploy --num-units 10) then the leader unit will probably not be unit/0, but, say, unit/8. At that point, if you scale down to below the leader unit (e.g. -4), a leadership change will occur and some other unit (impossible to predict which one) will receive
Disclaimer: for a known issue with this see: pytest-operator/42
In Ops, you can register event hooks to observe leadership change,
With Ops, you can test for leadership with
When writing unit tests with the OF harness, leadership is set with
Last updated 6 days ago.