|
model destroyed OK, then --force orphaned it and took the controller DOWN
destroy-model returned 'Model destroyed.' EXIT 0 with a clean progressive drain (36/56 -> 26 -> 20 -> 16 -> 9 -> 0) and a correct MAAS release: census 10, count UNCHANGED, nine nodes Ready/owner=None, controller VM still Deployed. Proxies PASS. M.4 model-defaults corrected and read back. Then add-model refused: model already exists, stuck at life: dead. Root cause from the controller log -- the destroy left the model doc alive while its STATUS doc was gone. undertaker crash-loops on 'cannot set status: model not found'; modelcache crash-loops on 'status doc <uuid>:e not found' (732 iterations in ~12 min). The API server depends on modelcache, so 17070 is connection refused and THE CONTROLLER IS DOWN -- while the VM pings and systemctl reads active. A jujud restart did not fix it. LP #1737487 class. OWNED, two of my decisions are implicated: I carried --force --no-wait over from the 07-31 stall where agents were STOPPED and force was genuinely required; this run's agents were ALIVE and draining, so force was almost certainly unnecessary and it is the documented cause of this inconsistency. And when the model would not reap I re-issued destroy against a model already dead, which moved it back to dying and re-armed the loop. Path M amended: try without --force when agents are alive; reserve --force --no-wait for the measured stall; never re-issue destroy on a dead model; if the controller is already down on this symptom, rebuild the controller rather than attempt state-DB surgery. Not degrading: nine nodes Ready, MAAS healthy, both proxies PASS, model-defaults now controller-level. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf |
|---|
|
|
| docs/CURRENT-STATE.md |
|---|
| runbooks/dc-dc-teardown-rollback.md |
|---|