destroy-model-blast-radius-20260802.txt
=======================================
Pre-mutation verification of `juju destroy-model vr1-dc0`, requested by the operator:
"We have had issues previously when a destroy has had a larger blast radius then
intended. Review and confirm that the command will only destroy what is intended."

Well-founded: this repo has a logged cascade (2026-07-21, a MAAS pod delete taking its
linked machine records with it). Everything below is MEASURED on the live controller
from the dc0 rack (D-138), not reasoned from the man page.

--------------------------------------------------------------------------------------
1. FLAG SEMANTICS -- `juju help destroy-model`, juju 3.6.27, THIS controller
--------------------------------------------------------------------------------------
Summary line: "Terminate all machines/containers and resources for a NON-CONTROLLER
model."  -> the controller model is out of scope BY DESIGN, not by our care.
  --no-prompt       EXISTS. (Confirmed -- the Details prose still says "-y", which is
                    STALE; the flag list is authoritative. Do not use -y.)
  --destroy-storage "Destroy all storage instances in the model"
  --release-storage "Release ... without destroying them"
  --force           "removes all units ... and, potentially, machines without giving
                    them the opportunity to shutdown cleanly"
  --no-wait         "Rush through model destruction without waiting for each step"
  --timeout         WARNING in help: --force WITH --timeout continues "without
                    consideration or respect for clean shutdown or resource cleanup"

--------------------------------------------------------------------------------------
2. WHAT IS ACTUALLY IN THE MODEL
--------------------------------------------------------------------------------------
  juju storage -m vr1-dc0      -> "No storage to display."   ZERO storage instances
  juju storage -m controller   -> "No storage to display."
  juju offers  -m vr1-dc0      -> EMPTY (no cross-model offers)
  juju models                  -> controller (1 machine) + vr1-dc0 (36 machines/45 units)

>>> FINDING A -- `--destroy-storage` IS A NO-OP HERE AND IS BEING DROPPED. <<<
The model has NO juju-managed storage, so the flag destroys nothing. I proposed the
DESTRUCTIVE storage flag for a model with no storage. ceph-osd's `osd-devices` are RAW
BLOCK DEVICES set by charm config, not juju storage instances -- which is exactly why
`juju storage` is empty. They are re-partitioned by MAAS at re-image. Neither storage
flag is required: juju only demands one when persistent storage exists.

>>> FINDING B -- NO CROSS-MODEL BLAST RADIUS. <<<
Zero offers means no other model consumes a relation from vr1-dc0, so nothing outside
this model loses an endpoint. The `controller` model is a separate model and is
explicitly out of destroy-model's scope.

--------------------------------------------------------------------------------------
3. WHAT HAPPENS TO THE NINE MAAS NODES
--------------------------------------------------------------------------------------
  maas dc0 maas get-config name=enable_disk_erasing_on_release -> false

So release does NOT trigger a disk-erase cycle; the nodes return to `Ready` promptly and
are re-imaged by the redeploy. (`disk_erase_with_secure_erase=true` /
`disk_erase_with_quick_erase=false` are the modes that WOULD apply if erasing were on --
they are inert while the master switch is false.)

MEASURED CORRECTION, recorded because a future session would guess it wrong: on the dc0
REGION VM the MAAS CLI profile is **`dc0`**, NOT `vr1-dc0-region`. The tool's own error
enumerated the valid choices. Profile names are PER HOST -- assert, never assume.

--------------------------------------------------------------------------------------
4. THE COMMAND, AS APPROVED FOR REVIEW
--------------------------------------------------------------------------------------
  juju destroy-model vr1-dc0 --force --no-prompt

DELIBERATELY NOT PASSED:
  --destroy-storage  no-op (Finding A) and it is the destructive one
  --release-storage  also unnecessary -- there is no storage to release
  --no-wait          help says it rushes steps; let each step complete
  --timeout          help warns --force + --timeout abandons clean shutdown

IN SCOPE:  the vr1-dc0 model only -- 45 units, 36 machines/containers.
OUT OF SCOPE, and none of it is touched: the `controller` model and the juju controller
VM, the MAAS region and its database, the 9 MAAS machine RECORDS (released to Ready, not
deleted), the rack host, the OPNsense edge, the apt caching proxy, the snap proxy, the
tofu substrate, and dc1 in its entirety.

POST-CHECKS (run immediately after, before recreating the model):
  (a) `juju models` shows ONLY `controller`
  (b) MAAS machine COUNT is unchanged and the 9 role nodes read `Ready` -- a DROP in
      count is the cascade signature from the 2026-07-21 incident and means STOP
  (c) `dc-cache-proxy.sh check dc0` and `dc-snap-proxy.sh check dc0` still PASS