Path M: the juju MODEL teardown + release path, from the runs we already logged
...
Operator: "You have that information from previous teardowns for the juju
release path ... find the previously logged information in the repo. Log the
commands and steps for future reference ... this has bit in the past and will be
a reusable and needed set for the future."
I had said the release path was the one thing I could not prove in advance. It
was already proven and logged, in CURRENT-STATE under MODEL TEARDOWN 2026-07-31.
Two corrections to the command I proposed:
1. --no-wait BELONGS IN IT and I had excluded it, reasoning from juju help that
it was reckless. Measured 07-31: the plain destroy-model STALLED TERMINALLY --
'attempt 30 ... model not empty, found 26 machines, 37 applications', flat ~19
minutes, application set byte-identical, because ALL 26 agents were stopped so
no teardown hook could execute. --force --no-wait cleared it (18->5->2, then
Model destroyed.). The help text talks you out of the flag that works.
2. The release path is proven, not unknown: all nine role nodes came back
Ready/owner=None, zero stranded, no maas machine release needed or run.
Expected post-state is 9 Ready + 1 Deployed -- the controller VM stays
Deployed in the controller model, so expecting 10 raises a false alarm.
Also recovered, and live for this rebuild: destroy-model TAKES THE MODEL CONFIG
WITH IT. On 07-31 that silently removed apt-mirror and the spaces work and
nothing in the repo would have caught it. Measured today: this controller's
model-defaults carry apt-mirror=http://10.12.8.4/ubuntu and nothing else -- wrong
after the convergence -- while the three settings the deploy needs were set at
MODEL level and will be destroyed. Defaults apply to NEW models only, so they
must be fixed BEFORE add-model.
And the VR0 pod warning does not transfer: VR0's virsh-POD MAAS decomposes
pod-composed machines on destroy-model; VR1 uses per-machine power_type=virsh,
not pods, so there is nothing to decompose.
The teardown runbook documented only SUBSTRATE teardown -- the model layer had no
procedure, which is why this kept being re-derived. Now Path M, M.0-M.6.
Final command: juju destroy-model vr1-dc0 --force --no-wait --no-prompt
BLOCKED by the permission layer and NOT run; no workaround attempted.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf
