Guarantee leadership revoked from departing unit before departed hooks run
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Triaged
|
Low
|
Unassigned |
Bug Description
If a lead unit is destroyed, it will make detrimental decisions when its relation-departed hooks are run if it still thinks it is the leader.
We must guarantee a new leader is elected before running departure hooks on the departing unit.
A special case will be needed if the service is being destroyed or if the leader is the sole remaining unit.
This may be worked around if the departing unit can detect that it is being destroyed (not currently possible), but charm authors would need to remember to guard for this special case.
As an example, if the lead unit in a PostgreSQL service is destroyed it will trigger a failover every time it sees the master unit departing the peer relation (appointing one of the remaining peers as master, which will shortly also depart from the leader's perspective). The surviving units cannot tell that these failovers are bogus, because they are unaware who the leader is and that it is being destroyed.
tags: | added: leadership |
Changed in juju-core: | |
status: | New → Triaged |
importance: | Undecided → Critical |
importance: | Critical → High |
Changed in juju: | |
status: | New → Triaged |
importance: | Undecided → High |
milestone: | none → 2.0.0 |
no longer affects: | juju-core |
Changed in juju: | |
milestone: | 2.0.0 → 2.0.1 |
Changed in juju: | |
milestone: | 2.0.1 → none |
Implementing this functionality will also minimise perceived leaderless interval as per bug # 1668238.