To deal with lifetimes of CAAS objects, commit 36b4353d50430c8ca31b7a66d8a853e6db5cc5cc introduced killing the Leadership Tracker if the Uniter dies. However, it does so with a Worker.Kill() which kills the worker with no error, which the DependencyEngine then treats as "don't restart because I'm done". But the Uniter has a dependency on it, so the Uniter is unable to be restarted.
Where unit '3' of a CAAS application might go away, but wouldn't stop the Leadership Tracker, which meant unit 4 couldn't become a leader. This doesn't happen in IAAS because we run a separate agent, and that agent dies when the unit is removed (vs in CAAS where we run all unit agents as a dependency from the application).
To deal with lifetimes of CAAS objects, commit 36b4353d50430c8 ca31b7a66d8a853 e6db5cc5cc introduced killing the Leadership Tracker if the Uniter dies. However, it does so with a Worker.Kill() which kills the worker with no error, which the DependencyEngine then treats as "don't restart because I'm done". But the Uniter has a dependency on it, so the Uniter is unable to be restarted.
We should decouple restarting the workers.
If we just removed the catacomb.Init here: /github. com/juju/ juju/blob/ 4530b4ddf5be45d f371438fb7f20ef 12b80a7d67/ worker/ uniter/ uniter. go#L207
https:/
Then it would regress this PR: /github. com/juju/ juju/pull/ 10087
https:/
Where unit '3' of a CAAS application might go away, but wouldn't stop the Leadership Tracker, which meant unit 4 couldn't become a leader. This doesn't happen in IAAS because we run a separate agent, and that agent dies when the unit is removed (vs in CAAS where we run all unit agents as a dependency from the application).