Pass 1 -- Worker W1.1: redeploy/teardown PLANNING under the confirmed Option-1 target

Author: W1.1 (Phase 1, container-elimination pass). Date: 2026-08-09. Scope: what the CONFIRMED Option-1 target topology (pass0-admin-report.md Section 7a) changes in the teardown and redeploy PLANNING ARTIFACTS -- runbooks/dc-dc-teardown-rollback.md, the runbooks/dc-dc-phase0..6*.md runbooks, and how D-143's re-IP interleaves with the container-elim change-set in the redeploy sequence. READ-ONLY. No mutation, no live commands. Every claim below is anchored to a path:line read this session; where a value is not yet knowable it is marked UNKNOWN with what resolves it.

Reminder of the confirmed target (do not re-derive): flat node VMs directly on vcloud libvirt; vvr1-dcN ELIMINATED; a small non-hypervisor vr1-dcN-client VM (metal-admin + transit legs) inherits the D-138 client role + that DC's credential residencies; MAAS region stays on vr1-dcN-maas-01 unchanged; rack-controller remainder / D-131 forwarder / artifact service placement is OPEN (client VM vs maas-01, carried into this phase per Section 6 item 3 of pass0-admin-report.md); cross-DC isolation (a) is a REQUIRED Phase-1/2 design deliverable (a new vcloud-level host isolation control); this rides D-143 but must stay DISTINGUISHABLE from it.

1. The teardown-primitive answer

Today: runbooks/dc-dc-teardown-rollback.md's whole structure is built on the D-123 Model-B TWO-ROOT/TWO-HOST shape -- an OUTER root on vcloud that creates vvr1-dcN, and an INNER root run FROM THE OFFICE1 HEADEND (voffice1) via qemu+ssh into the containment VM (lines 26-65, the "MODEL B RESHAPE" banner; lines 136-152, "TWO CLONES, TWO HOSTS"). D-122's site-down lever is explicitly one object: virsh destroy vvr1-dcN (line 48). Every Path (A/B/C/M) is written against this shape.

Under Option 1, the two-root/two-host shape COLLAPSES to one root on vcloud. There is no containment VM to hold an inner libvirt, so there is no qemu+ssh provider dial, no inner state file on voffice1, and no D-122 single-object site-down (that lever is explicitly named a "REAL D-123 regression to carry honestly" in pass0-admin-report.md row 9). The teardown primitive becomes:

A single-root, module-scoped tofu destroy per DC, run entirely on vcloud -- tofu destroy -target=module.vr1_dcN_planes -target=module.vr1_dcN_node -target=module.vr1_dcN_wan -target=module.vr1_dcN_opnsense -target=module.vr1_dcN_client -target=module.vr1_dcN_storage (module names illustrative -- Phase 2/W2.1 owns the real post-flattening module names), OR (preferred, since a flat root holding exactly one DC's resources needs no -target at all, same logic the current runbook already uses for the per-DC INNER root, lines 751-758) one dedicated root per DC so a plain tofu destroy there is inherently scoped -- re-earning the "scope by choosing the root" discipline (current lines 155-168) without a second host.

This is the group-destroy of the vr1-dcN-* domain set, not a single-object destroy -- D-122's convenience is genuinely lost, and Section 5's cross-DC isolation gap (Section 5) is one more reason NOT to try to re-earn it via "add a synthetic wrapper VM back" -- that would just re-import the eliminated pattern. The honest replacement discipline: (a) a tofu-level group-destroy scoped by root/module (safe, plan-reviewable, the mechanism above), and (b) for a "stop this DC's compute NOW" emergency lever (the actual use case D-122's single-virsh convenience served), a SCRIPTED loop over virsh destroy for the named domain set derived from lib-hosts.sh's roster for that DC -- not a manual enumeration. Both are NEW artifacts this pass must hand to Phase 2/4 (tooling + module design), not something already built.

1.1 Per-Path change list

Net verdict on this runbook: it needs a REWRITE comparable in scope to the 2026-07-16 "MODEL B RESHAPE" banner that was bolted on for the previous topology change -- likely the same pattern (a prominent "OPTION-1 FLATTEN" banner up top plus the Steps re-grouped), not a line-by-line patch. Paths M and C are the two genuinely LOW-delta paths (they sit above the substrate layer entirely); Paths A/B and the rollback tree carry the real rewrite weight.

2. Per-phase-runbook change list

2.0 What does NOT change

• runbooks/dc-dc-phase0-vcloud-prep.md -- grep for vvr1-dc/containment/qemu+ssh/ inner root/outer root returns ZERO hits in the body (only a generic qemu+ssh://... example at :113,123 describing the libvirt-URI syntax itself, and libvirt_uri = "qemu:///system" # or qemu+ssh://... -- Step 1 at :364, which is the OUTER root's own provider block, unaffected). This runbook covers vcloud host prep, the D-100 mesh triangle, storage pools, the shared base image -- none of it is containment-specific. No change required.
• runbooks/dc-dc-phase1-office1-standup.md -- its "containment VM" is voffice1 under D-114, a DIFFERENT decision than D-123's Model-B DC containment (:9,13,44-47,313-337 -- D-114 is cited by name throughout, never D-123). voffice1 simulates the Office1 FACILITY and hosts MAAS-region/LXD for MAAS-composed service VMs (NetBox, tailscale) -- it is not the object the container-elim pass targets, and Phase-0's scope explicitly named the container layer as vvr1-dcN only (SCOPE-AND-EXECUTION-PLAN.md Sec 2, pass0-admin-report.md Sec 1.3 "It is NOT: ... the DC edge ..." -- Office1 wasn't even in scope). No change required for THIS pass. Flag for the record: D-114's own containment pattern is architecturally the same shape D-123 used, and if the operator's "eliminate the container layer" intent is read as broader than the Phase-0 gate scoped it, that is a SEPARATE decision outside this pass's mandate -- not assumed here.

2.1 runbooks/dc-dc-phase2-tofu-dc-substrate.md -- the largest single change

This runbook IS the two-root apply sequence, and its "D-123 MODEL B RESHAPE" callout (:144-204) is the direct predecessor of the change this pass makes. Per-step:

Net verdict: Phase 2 needs the SAME weight of rewrite as its own prior D-123 reshape -- arguably heavier, since this pass ELIMINATES a whole apply stage (B) rather than adding one.

2.2 runbooks/dc-dc-phase3-maas-enlist-deploy.md

• :424,430 -- ssh -i ~/vr1-dcN-creds/... -J voffice1 jessea123@<dcN-rack-transit-ip> 'sudo bash -s' -- check dcN < scripts/dc-mirror.sh (dc0) / dc-cache-proxy.sh (dc1). Today's assumption: the jump target is the rack transit IP, i.e. the CONTAINMENT VM (vvr1-dcN's own transit leg, per lib-hosts.sh's VIRSH_POWER_ADDRESS). Option-1 change: the jump target becomes vr1-dcN-client's transit IP -- the artifact-service check (dc-mirror/dc-cache-proxy) still runs via SSH-through-voffice1 into the DC, but the far end of that hop is a different (non-hypervisor) VM. The artifact-service PLACEMENT itself (client VM vs. vr1-dcN-maas-01 vs. retire) is the OPEN item from pass0-admin-report.md Section 6 item 3 -- if it lands on maas-01 instead, this whole SSH target changes to that VM's address, not the client VM's. UNKNOWN pending that placement ruling; do not pick one here.
• Everything else in Phase 3 (MAAS enlist/commission/deploy of the node fleet, Steps 1-7 generally) is about MAAS machine-level operations against a fleet that is already flat from MAAS's point of view TODAY (per-machine power_type=virsh, no pod) -- pass0-admin-report.md confirms this is NOT a two-root/containment-keyed concern (row 4/5: only the POWER ADDRESS changes, the mechanism is topology-agnostic). Low delta beyond the two SSH-target lines above.

2.3 runbooks/dc-dc-phase4-juju-bundle-per-dc.md

• :158-185, the "RUN LOCATION" table -- this is the runbook's own record of getting D-138 wrong once already (superseded text quoted at :169-178: "Every juju and maas command runs on voffice1" was WRONG; D-138 moved juju/openstack CLI onto "THIS DC's RACK"). Under Option 1, "THIS DC's RACK" is retired vocabulary -- the concrete host D-138's principle points at becomes vr1-dcN-client (per pass0-admin-report.md Sec 3.3, Option 1's client VM is "consistent with D-138's principle"; the concrete-host CHANGE still needs recording, Phase 4's [ARCH] decision). This table needs a THIRD correction pass: row 1 ("juju/openstack CLI") -> runs on vr1-dcN-client, not "the rack" (the rack as a distinct host no longer exists); row 2 (maas/NetBox/tofu) stays on voffice1, UNCHANGED (D-128 Plane 2 survives -- MAAS region and NetBox are not containment-layer objects); row 3 (never vcloud) UNCHANGED.
• :180-185, the staged-scripts caveat -- "the rack has NO repo clone" and needs ~/repo-stage/scripts/ staged there. This caveat TRANSFERS verbatim to vr1-dcN-client (still a non-repo-clone host by design, same staging discipline needed) -- no logic change, just a re-pointed noun.
• :840-848, the "considering destroying anything BELOW the juju layer" caution -- names "the containment VM, the DC's libvirt resources, MAAS records" and points at the (currently Model-B-shaped) teardown runbook. Needs updating to point at the REWRITTEN teardown runbook (Section 1 above) and drop the containment-VM noun -- the caution's PRINCIPLE (don't reach for a substrate destroy while nodes are MAAS-enrolled) is unchanged.
• Path M and Path C content itself (the juju model/controller procedures phase4 delegates to the teardown runbook) needs NO change here -- confirmed low-delta in Section 1.

2.4 runbooks/dc-dc-phase5-dr-failover-drill.md

• No vvr1-dc/containment/qemu+ssh hits (grep confirmed). Its only execution-host reference worth flagging is INDIRECT: it delegates the per-DC deploy command to Phase 4 (:430-433) and otherwise operates at the juju/openstack layer, which is D-138-scoped (client VM under Option 1) rather than containment-scoped. No direct edit required by container-elim; it inherits whatever Phase 4's table says.

2.5 runbooks/dc-dc-phase6-designate-cos-magnum.md

• :437-444 -- "juju is ABSENT on vcloud ... Run them from the Plane-2 host (voffice1) per D-128" and "CHECK (read-only) -- from the Office1 headend (voffice1)" immediately precedes a juju status -m ... command. This is ALREADY WRONG independent of the container-elim -- it predates phase4's own D-138 correction (juju runs on the DC's execution host, not voffice1; pass0-admin-report.md and phase4's :174-178 both confirm juju controllers on voffice1 returns "No controllers registered"). Flagging here because the SAME fix phase4 needed (rack -> client VM) applies to this line too, and both should be corrected in the SAME pass since they share the root cause (a stale D-138 pointer). Not itself a NEW container-elim delta, but a pre-existing defect this pass's rewrite sweep should not leave behind.

2.6 runbooks/dc-dc-office1-service-reip.md

• Entirely Office1-scoped (voffice1's own MAAS-composed LXD VMs -- NetBox, tailscale). No vvr1-dcN reference; out of this pass's scope (D-114, not D-123).

3. D-143 (re-IP) vs. container-elim: keeping the two axes distinguishable in the redeploy sequence

D-143's OWED EXECUTION list (docs/design-decisions.md:8163-8174) is FIVE items, all address-only:

1. NetBox apex -- new B2 role Cloud -- VR1 rebuild owning 10.13.0.0/16; re-carve VR1 prefixes/VIPs/ranges under it, octet-preserving.
2. scripts/lib-net.sh -- flat defaults STAY 10.12; vr1-dc0/vr1-dc1 arms get full 10.13 literal blocks; fix the stale ":124-134" comment.
3. 10.13 naming-collision DOCFIX (netbox/README.md:49, a test literal).
4. D-124 transit routes re-point + rack statics shift (10.12.8.2 -> 10.13.8.2, etc.).
5. Teardown must REVOKE the dc0-substrate credentials before redeploy.

None of these five items touch topology -- they are a value substitution (12->13) plus one NetBox role-model addition. The container-elim change-set is orthogonal: it changes WHICH objects exist and WHERE they run, not what numbers they carry. Concretely, keeping them distinguishable in the redeploy plan means:

• Sequence within one redeploy, not two redeploys. Since both changes ride the SAME teardown+rebuild, the interleave is: (i) teardown the CURRENT 10.12 Model-B checkpoint (Section 4 below) -- an ADDRESS-AGNOSTIC, TOPOLOGY-AGNOSTIC action (you're destroying objects, not re-carving them); (ii) apply D-143 item 1 (NetBox apex) and item 2 (lib-net.sh literal blocks) as the FIRST rebuild inputs -- these are pure data, no topology dependency, so they can be done before or independent of the module rewrite; (iii) rebuild against the Option-1 flat module design (this pass's Phase 2/4 deliverable), consuming the NEW 10.13 literals from step (ii) -- the flat root's tfvars/module calls reference lib-net.sh's 10.13 arm the same way the old two-root shape referenced its 10.12 arm, so the flattening and the re-IP compose cleanly (one substitutes VALUES, the other substitutes SHAPE) rather than colliding.
• Attribution discipline for the change-set (Phase 4's job, flagged here so it isn't lost): every diff in the rebuilt opentofu/ tree should be traceable to EITHER "this line's value changed because of D-143" OR "this line/module/step exists or doesn't because of container-elim" -- not both folded into one undifferentiated rewrite. A rewritten Phase-2 runbook that silently also renumbers octets (or vice versa) would make a future revert-one- axis-not-the-other impossible to reason about. Concretely: the module RENAME/RESTRUCTURE (e.g., module.vvr1_dc0 disappearing, module.vr1_dc0_client appearing) is container-elim; the VALUES inside surviving modules changing from 10.12.x to 10.13.x is D-143. A resource that is BOTH new AND carries a 10.13 literal (e.g., the client VM's transit IP) is fine to create once, but its commit/changelog framing should name both governing changes, not blur them into "the redeploy."
• D-143 item 5 (revoke dc0-substrate credentials before redeploy) interacts directly with the container-elim's credential-residency migration (pass0-admin-report.md row 8 / Section 6 item 6): the OLD credentials being revoked are resident on the (about to be eliminated) vvr1-dc0; the NEW credentials being minted for the rebuild are resident on vr1-dc0-client. This is naturally sequenced (revoke old -> destroy old host -> build new host -> mint new credential) but it means D-143 item 5 and the container-elim's SEC-028/ SEC-029 re-pointing are the SAME step wearing two decision-labels -- call it out as one action justified by both D-NNNs when it's executed, not two separate ones.

4. Teardown of the CURRENT (Model-B, 10.12) live checkpoint -- order

This is the FIRST action of the redeploy (dc0 is already at the confirmed FULL-deployment checkpoint per the operator's pivot memory; dc1 is held). Per the teardown runbook's own discipline (Section 1 above, still valid for tearing down the CURRENT Model-B shape -- the runbook doesn't need to be rewritten to tear down what it already describes correctly):

1. Path M first, per DC with a live model -- tear down the juju MODEL(s) before touching substrate (dc-dc-teardown-rollback.md Path M, :188-392). This is the D-143 item-5 credential-revoke's natural anchor point too (revoke, then destroy).
2. D-143 item 5 -- revoke the dc0-substrate credentials (folded into or immediately after step 1, per Section 3 above).
3. Path C, if a controller needs to come down with the model (only if the controller itself is being retired, not just the model) -- :394-596.
4. Path B substrate teardown, ordered INNER then OUTER, per DC -- :914-957: from voffice1, tofu destroy each opentofu/vr1-dcN-substrate/ root; THEN, on vcloud, tofu destroy the outer root's vvr1_dc0/vvr1_dc1/vr1_dcN_uplink/vr1_dcN_storage modules. Step 2's MAAS census (:635-747) runs FIRST, per DC, before any destroy -- this is unaffected by container-elim (still the load-bearing "attribute every power_type=virsh record" gate).
5. Mesh legs -- destroy ONLY if the whole VR1 layer (both DCs) is going away together (:960-995); a checkpoint-then-redeploy that keeps the SAME two DCs (new IPs, new shape, same DCs) should almost certainly PRESERVE the mesh triangle and simply let the flat rebuild re-target it -- destroying and recreating the mesh legs is extra churn with no benefit unless the mesh module ITSELF needs to change shape for the flat topology (UNKNOWN pending Phase 2/W2.1's tofu-module design -- the mesh legs are NOT named as changing in pass0-admin- report.md's "persists" list, Sec 1.3, so the working assumption is they survive; confirm at Phase 2, don't destroy speculatively).
6. Only after 1-5 converge (Step 5's untargeted tofu plan gate, :894-911, showing zero unexpected drift) does the rebuild begin -- against the Option-1 flat module design, consuming D-143's new NetBox/lib-net.sh literals per Section 3's sequencing.

This order is UNCHANGED by container-elim -- it is the teardown runbook's existing Path M -> C -> B ordering, applied to what is CURRENTLY built (Model-B, 10.12). Container-elim only changes what gets BUILT next (Section 2), not the order in which the current thing comes down.

5. Open items this pass surfaces (not resolved here -- feed to Phase 2/4)

1. Root topology: one merged root per DC, or a shared outer + per-DC root split retained minus the containment seam? Section 1/2.1 above illustrate BOTH as plausible; Phase 2/W2.1 (OpenTofu module design) is where this gets decided, not this planning pass. This document's tofu destroy illustrations are DELIBERATELY marked illustrative for that reason.
2. The new teardown-primitive script (module-scoped group-destroy / virsh destroy loop) does not exist yet -- it is a NEW tested artifact this pass identifies as owed, to be built and harnessed per repo discipline (CLAUDE.md "Delivery") once the module design lands.
3. D-128's Plane-1/Plane-2 split is written entirely around the two-root shape (docs/design-decisions.md:5354-5364). Under Option 1 there is no more "Plane 2 = the INNER tofu root run from voffice1" -- Plane 2 shrinks to MAAS/NetBox only (tofu is now entirely Plane 1, vcloud). This is a D-128 amendment this pass's Phase 4 [ARCH] framing should fold in alongside the D-123 container-elim ruling itself -- flagged here because it was found while reading phase2/phase4's execution-host tables, not because W1.1 is ruling on it.
4. Artifact-service / rack-controller-remainder / D-131-forwarder placement remains OPEN (pass0-admin-report.md Section 6 item 3) and DIRECTLY determines the SSH-jump-target edit in Section 2.2 above and the maas-vm-host re-homing in Section 2.1's Step-D row. This pass's findings are written generically ("client VM OR maas-01") precisely because that placement is not yet ruled -- do not let a later pass silently pick one without updating both citations here.

6. Verification note

Every path:line cite above was read directly this session from runbooks/dc-dc-teardown- rollback.md, runbooks/dc-dc-phase0-vcloud-prep.md through phase6-designate-cos-magnum.md, runbooks/dc-dc-office1-service-reip.md, opentofu/main.tf (module list), and docs/design-decisions.md (D-128, D-143). No value in this document is inferred from a prior session's summary or from memory -- where a placement or a module name is not yet knowable it is marked UNKNOWN with what resolves it, per hard rule 2.