Juju loses track of current controller when destroying model
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Fix Released
|
High
|
Unassigned | ||
juju-ci-tools |
Fix Released
|
High
|
Michael Skalka |
Bug Description
I just saw this, not sure how to debug further. The TL;DR is that I was able to list models, but when I destroyed the model I was currently attached to, it seemed unable to fall back to a different model. Worse, it seemed to lose track of the admin and default models entirely until I switched to the admin model.
mark@mark-
NAME OWNER STATUS LAST CONNECTION
admin admin@local available never connected
default admin@local available 22 hours ago
bigdata* admin@local available 21 hours ago
mark@mark-
WARNING! This command will destroy the "bigdata" model.
This includes all machines, services, data and other resources.
Continue [y/N]? y
mark@mark-
ERROR cannot list models: model not found (not found)
mark@mark-
ERROR refreshing models: model not found (not found)
mark@mark-
CONTROLLER MODEL USER SERVER
local.test* bigdata admin@local 192.168.
mark@mark-
local.test:bigdata (no change)
mark@mark-
local.test:bigdata -> local.test:admin
mark@mark-
NAME OWNER STATUS LAST CONNECTION
admin* admin@local available never connected
default admin@local available 22 hours ago
mark@mark-
[Services]
...
Related branches
- Curtis Hovey (community): Approve (code)
- Aaron Bentley (community): Approve
-
Diff: 348 lines (+339/-0)2 files modifiedassess_destroy_model.py (+164/-0)
tests/test_assess_destroy_model.py (+175/-0)
Changed in juju-core: | |
milestone: | 2.0-beta8 → 2.0-beta9 |
Changed in juju-core: | |
milestone: | 2.0-beta9 → 2.0-beta10 |
Changed in juju-core: | |
milestone: | 2.0-beta10 → 2.0-beta11 |
Changed in juju-core: | |
milestone: | 2.0-beta11 → 2.0-beta12 |
tags: | added: 2.0 bitesize |
Changed in juju-core: | |
milestone: | 2.0-beta12 → 2.0-beta13 |
Changed in juju-core: | |
milestone: | 2.0-beta13 → 2.0-beta14 |
Changed in juju-core: | |
milestone: | 2.0-beta14 → 2.0-beta15 |
Changed in juju-core: | |
milestone: | 2.0-beta15 → 2.0-beta16 |
Changed in juju-core: | |
milestone: | 2.0-beta16 → 2.0-beta17 |
affects: | juju-core → juju |
Changed in juju: | |
milestone: | 2.0-beta17 → none |
milestone: | none → 2.0-beta17 |
Changed in juju: | |
status: | Fix Committed → Fix Released |
Changed in juju-ci-tools: | |
assignee: | nobody → Michael Skalka (mskalka) |
status: | Triaged → In Progress |
Changed in juju-ci-tools: | |
status: | In Progress → Confirmed |
status: | Confirmed → Fix Released |
status: | Fix Released → Fix Committed |
Changed in juju-ci-tools: | |
status: | Fix Committed → Fix Released |
I think there may be two issues here:
1 - We don't unset the "current model" if you destroy the model you're currently operating on. Bug #1505504 can track that fix.
2 - There's a timing hole in list-models where we first get all models, then query each one for more details. A model which has been removed during that timing hole would result in the error you saw. While we're iterating over the models, if we encounter one that no longer exists, we should not fail the whole operation. That model should just be removed from the results.