leader-elected event is emitted for a unit that is elected as leader. Together with
leader-settings-changed, it is one of two “leadership events”. A unit receiving this event 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. The same holds if the unit checks leadership by
Unit.is_leader(): if the result is
True, then the unit can be ensured that it has leadership for the next 30s.
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 (>30s), 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-createdduring the Startup phase. However, by the time
relation-createdruns, juju may already have a leader. This means that, in peer-relation-created handlers, it might already be the case that
Trueeven though the unit did not receive a leadership event yet. If the starting unit is not leader, it will receive a
|Start new unit
juju deploy foo
juju add-unit foo
install -> (*peer)-relation-created -> leader-elected
- During the Operation phase, leadership changes can in principle occur at any time, for example if the leader unit is unresponsive for some time. When a leader loses leadership it will only receive a
leader-settings-changedevent, just like all the other non-leader units. The new leader will receive
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 few cli tools, including
That will cause the lease to expire within 60s, and another unit of the same application will be elected leader and receive
- If the leader unit is removed, then one of the remaining units will be elected as leader and see the
leader-electedevent; all the other remaining units will see
leader-settings-changed. If the leader unit was not removed, no leadership events will be fired on any units.
Note that unless there’s only one unit left, it is impossible to predict or control which one of the remaining units will be elected as the new leader.
|Current leader loses leadership
juju remove-unit foo
(all other foo units):
ops, you can observe this event like you would any other:
# in MyCharm.__init__
leader-elected event object does not expose any specific attributes.
When writing unit tests with the OF harness, leadership is set with