Juju fails to restore state-server on xenial
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
juju-core |
Won't Fix
|
Undecided
|
Unassigned | ||
1.25 |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
As seen in
http://
Note, backup and restore works properly when using trusty, but fails per above using xenial. It's unclear if this ever worked due to our recent ability to see this type of failure. Note bug 1637234 which should help in seeing these types of problems in the future.
------------------
Leaving Curtis's notes here from IRC as well;
Our test stratgy changed, which allows us to see the 1.25 services did not see the config-changed event. (so hosted model is not the true case here)
I backtested a 1.25 from June and it failed the same way. So if this is a regression it is old. Maybe 1.25 could never restore a xenial state-server, but Juju *claims* it did. more investigation is needed
The error is consistent when we backtest older 1.25. but I think we should back test further to learn if 1.25 could never truly restore a xenial deployment. The state-server is fine, but *all* the unit are lost. I suspect the units were not properly updated to look at the new ip address.
tags: | added: ci |
Changed in juju-core: | |
milestone: | 1.25.8 → none |
Changed in juju-core: | |
milestone: | none → 1.25.11 |
Note, this is not a regression from 1.25.6 as it was also broken in that build.