leader-elected fails if leadership was lost in the meantime, breaking sync
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ubuntu-repository-cache (Juju Charms Collection) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
If a unit is deposed with the leadership-elected hook queued, and leadership-elected subsequently runs, it fails messily and blocks syncs, e.g.:
2017-09-07 20:52:43 ERROR juju.worker.
2017-09-07 20:53:01 WARNING juju.worker.
2017-09-07 20:53:02 INFO leader-elected error: cannot write leadership settings: cannot write settings: not the leader
2017-09-07 20:53:02 INFO leader-elected Traceback (most recent call last):
2017-09-07 20:53:02 INFO leader-elected File "/var/lib/
2017-09-07 20:53:02 INFO leader-elected HOOKS.execute(
2017-09-07 20:53:02 INFO leader-elected File "/var/lib/
2017-09-07 20:53:02 INFO leader-elected self._hooks[
2017-09-07 20:53:02 INFO leader-elected File "/var/lib/
2017-09-07 20:53:02 INFO leader-elected hookenv.
2017-09-07 20:53:02 INFO leader-elected File "/var/lib/
2017-09-07 20:53:02 INFO leader-elected return f(*args, **kwargs)
2017-09-07 20:53:02 INFO leader-elected File "/var/lib/
2017-09-07 20:53:02 INFO leader-elected subprocess.
2017-09-07 20:53:02 INFO leader-elected File "/usr/lib/
2017-09-07 20:53:02 INFO leader-elected raise CalledProcessEr
2017-09-07 20:53:02 INFO leader-elected subprocess.
2017-09-07 20:53:02 ERROR juju.worker.
This can be difficult to notice because by default Juju 2 will regularly retry the hook. Running "juju resolve --no-retry ubuntu-
Changed in ubuntu-repository-cache (Juju Charms Collection): | |
status: | New → Confirmed |