GitBucket
Pass 4 / W4.3 -- Execution sequencing into the teardown -> redeploy (module invocations)
READ-ONLY planning artifact. Container-layer-elimination pass, Phase 4, Worker 3. Confirmed ground truth consumed: pass0-admin-report.md Section 7a (Option 1; cross-DC handling (a); MAAS region stays on vr1-dcN-maas-01); pass1-admin-report.md Sections 3-7 (planning change-set, the (a)-control spec, the L0-L5 layer model); pass1-w3- sequencing.md (the base ordered sequence, adversarially corrected by the pass1 admin); pass2-admin-report.md Sections 2-5 (the THREE isolation concerns, the 13 owed artifacts, Phase-2 recommendation-grade resolutions); pass3-admin-report.md Sections 2-4 (the unified tests change-set, the gate-home map, the #11 critical-path constraint). No mutation proposed or performed here -- this is the ORDERED PLAN, expressed as module/artifact invocations, for later gated execution.
Layer model used (adopted from pass1-admin-report.md Section 5, W1.4's design -- NOT redefined here; W4.2 owns its full specification): L0 host/inter-site substrate -> L1 site/edge nodes (incl. the client VM as a cloudinit-vm instance) -> L2 DC substrate (planes + node VMs; the two-root split collapses into L2) -> L3 enlist/commission -> L4 Juju/OpenStack deploy (D-140 pins as procedure) -> L5 verify/gate (cross-cutting).
Axis tags throughout: [D-143] (value/address substitution) / [CE] (container-elim, shape change) / [both] (four confirmed dual-cause items, per pass1 check 5) / [unchanged] (persists across the pivot, neither axis's content).
0. Four critical-path invariants -- where each lands, verified against the sequence below
| # | Invariant (source) | Lands at | Verified honored |
|---|---|---|---|
| 1 | (a)-control BEFORE any flat substrate apply (pass1-admin-report.md Section 3; pass2-admin-report.md Section 2.1) |
B.3, before B.4 | YES -- B.3 gate-closes before B.4.0/B.4.1 open; B.4 is the first step that can co-locate two DCs' plane bridges on vcloud's kernel |
| 2 | Power-key mitigation (#11) BEFORE lib-hosts power-address re-derivation -- blocks a 6-item test cluster (pass3-admin-report.md Section 4) |
B.6.1, before B.6.2 | YES -- B.6.2 (the lib-hosts.sh edit) is sequenced strictly after B.6.1's mechanism ruling + C4 harness; B.6.2's own gate lists the same 6-item cluster as blocked-together |
| 3 | R7 revocation + MAAS record-release BEFORE substrate destroy (pass1-w3-sequencing.md Part A steps 3-4; Part E risk 4) |
A.3-A.4, before A.5-A.7 | YES -- A.3/A.4 precede the destroy-plan/apply steps A.5-A.7 in Part A below, unchanged from pass1's ordering |
| 4 | D-143 value-substitution kept attributable, separate from container-elim shape-change (SCOPE-AND-EXECUTION-PLAN.md Section 7; pass1 check 5) |
Every row's tag column | YES -- every step below carries its axis tag; the four genuinely dual-cause items (B.1.4, B.4/B.6.2 power-address, R7/A.3, B.7.1/B.7.4) are marked [both], not silently folded into one axis |
No step below violates any of the four; the invariant table above is the single cross-check a future session should re-run if this document is ever amended.
PART A -- TEARDOWN of the current 10.12 Model-B checkpoint
Baseline unchanged from pass1-w3-sequencing.md Part A (pass1-admin-report.md consumed it without correction) -- today's tooling (runbooks/dc-dc-teardown-rollback.md) tears down today's actually-deployed two-root shape; the flat-topology target does not change what commands remove the OLD shape.
| # | Module/artifact invoked | Layer (old shape) | Tag | Depends-on | Gate that closes it |
|---|---|---|---|---|---|
| A.1 | tofu state pull / backup, BOTH roots BOTH hosts (outer state on vcloud; each DC's inner state on the Office1 headend, D-128 Plane 2) |
L2 (old two-root) | [D-143] | -- | backup file exists for both roots, both hosts, verified present before proceeding |
| A.2 | MAAS machine census, from voffice1 -- LENS 1 (every power_type=virsh record) + LENS 2 (corroborate vs lib-hosts.sh pinned boot-MAC roster) |
L3 | [D-143] | A.1 | both lenses succeed; LENS 2 returns zero unattributed records |
| A.3 | R7 credential-revocation checklist (owed artifact #4) -- SEC-026 client cred, SEC-028 service cred, SEC-029 rack-local PKI copy (shred), D-126 per-env SSH keypair (clean retirement, no successor), MAAS rack enroll-secret residue; enumerated from EVERY vm-secret-locations row keyed to the rack/vr1-dcN-client host class, not only the named examples |
L5 (credential gate) | [both] -- owed BY D-143's re-IP ruling (owed-execution item 5); the credentials revoked are container-elim-eliminated host classes | A.2 (hosts still up and reachable) | every row individually confirmed revoked/shredded/rotated with captured command output (never asserted from memory); rows marked RETIRED, append-only |
| A.4 | MAAS machine-record release/delete [MUTATION, operator-gated per record class] (owed artifact #5, amended by pass2 to include maas rack-controller delete decommission of vvr1-dcN's Office1 registration + the region's primary_rack/DHCP reference) |
L3 | [D-143] | A.3 (revoke before the record that names the credential-bearing host disappears) | LENS 2 (A.2's check) re-run and now returns zero; region-side rack-controller/primary_rack residue confirmed clean |
| A.5 | Plan destroy, INNER root (opentofu/vr1-dcN-substrate/), from voffice1; capture pre-destroy virsh list/net-list/pool-list --all baseline while the containment VM is still reachable |
L2 (old inner root) | [D-143] | A.4 | plan reviewed; baseline captured |
| A.6 | Plan destroy, OUTER root (vcloud): -target=module.vvr1_dcN -target=module.vr1_dcN_uplink -target=module.vr1_dcN_storage only -- do NOT target mesh/netem modules (mesh triangle survives the pivot, confirmed at Phase 2/pass2 4.5) |
L1 (old containment shape) | [D-143] | A.5 | plan reviewed; mesh/netem legs confirmed excluded from the target set |
| A.7 | Apply destroys, INNER then OUTER (tofu destroy plans from A.5/A.6); verify each half from the host that can see it (inner via the containment VM's virsh before it's gone; outer via vcloud's own virsh after) |
L2 then L1 | [D-143] | A.6; each destroy individually operator-approved (hard rule 3 -- destructive steps never batched) | inner half destroyed + verified; outer half destroyed + verified |
| A.8 | Untargeted tofu plan drift gate (outer root; equivalent check on any surviving DC's inner root) |
L5 | [D-143] | A.7 | zero unexpected drift |
| A.9 | NetBox DCIM decommission of the vvr1-dcN device record(s) (netbox/dc-rack-mgmt-import.py) |
system-of-record (cross-layer) | [D-143] | A.7 confirmed gone | record marked decommissioned in live NetBox |
| A.10 | Repeat A.1-A.9 per DC (Path A) or run the Path B batched form for both DCs at once | -- | [D-143] | A.1-A.9 per DC | both DCs' checkpoints torn down and drift-gated |
A.10 note (site-down primitive): D-122's one-command site-down (virsh destroy vvr1-dcN) is still literally available during Part A (the shape being torn down still has it) but is NOT used raw here -- module-scoped tofu destroy is the reviewed, gated path (CLAUDE.md hard rule 4, the 2026-08-03 incident this rule exists to prevent). The PRIMITIVE'S REPLACEMENT for the new flat shape is a Part-B design note (B.0), not built or exercised during this teardown.
PART B -- REDEPLOY on flat 10.13 (Option 1), as module invocations
B.0 -- site-down primitive replacement (design note only; not an executable step)
Under Option 1 there is no single VM whose destruction equals "the DC is gone." The target-state primitive is one module/root-scoped tofu destroy against the flat root's vr1_dcN_* module set (owed artifact #1, root-shape-(B)-dependent; owed artifact #6 is the emergency virsh destroy loop over the same root's state-listed domains as a distinct non-gated lever). Neither is built during the redeploy itself -- noted here so B.4/B.8 do not read as having silently re-earned it without a delivered artifact.
B.1 -- prerequisites (run once, before any apply; GATES B.4)
| # | Module/artifact invoked | Layer | Tag | Depends-on | Gate that closes it |
|---|---|---|---|---|---|
| B.1.1 | dc-dc-whole-host-budget.py FIT-calculator extension + fresh vcloud capacity re-measurement (owed artifact #7, amended to include the 3 utility-node classes + artifact-service disk sizing) |
L5 | [both] -- D-143 needs it for rebuild sizing; container-elim needs it to convert "~176 GiB freed" from directional to measured | -- | >>> HARD GATE, closes before B.4's first apply <<< live-measured host budget + extended FIT verdict for the flat 12+1-VM/DC roster, both DCs; a roster total exceeding the measured budget must FAIL, not be rounded or omitted (test A8) |
| B.1.2 | NetBox apex re-carve: mint B2 role Cloud -- VR1 rebuild owning 10.13.0.0/16; re-carve VR1 prefixes/VIPs/ranges octet-preserving (D-143 owed-execution item 1) |
system-of-record | [D-143] | -- | 10.13 prefixes exist under the new role; Cloud (10.12) role confirmed untouched |
| B.1.3 | scripts/lib-net.sh: flat defaults stay 10.12 (vr0-dc0 no-op preserved); vr1-dc0/vr1-dc1 gain full 10.13 literal blocks; :124-134 stale "inherits VR0" comment corrected (D-143 owed-execution item 2, F13) |
L0 library | [D-143] | B.1.2 | tests/lib-validate green against the new literals |
| B.1.3a | 10.13 naming-collision DOCFIX (D-143 owed-execution item 3): netbox/README.md:49 and tests/dc-rack-mgmt-import/test_logic.py:265 reconciled so the /16 adoption doesn't leave a rack-IP test fixture inside the new Cloud space |
doc/test currency | [D-143] | B.1.2 | repo-lint clean; no residual 10.13.0.5-class fixture collision |
| B.1.4 | D-124 transit routes re-point + DC-side static shift (12->13) -- octet-preserving math is D-143; the BEARER host changes from vvr1-dcN's rack-transit IP to the new vr1-dcN-client VM's transit leg (CE) |
L1 (client-VM identity) / L0 (transit) | [both] | B.1.2 | NetBox shows the client VM's transit /30 address; carried into B.4's client-VM module inputs |
B.2 -- Office1 + vcloud prep (persists, off the container layer entirely)
| # | Module/artifact invoked | Layer | Tag | Depends-on | Gate |
|---|---|---|---|---|---|
| B.2.1 | vcloud host prep (Phase-0 runbook) | L0 | [unchanged] | -- | existing Phase-0 runbook gate |
| B.2.2 | Office1 headend standup (Phase-1 runbook), if not already up from the dc0 checkpoint -- voffice1 remains MAAS region host (D-132 addendum, unaffected) and remains Plane-2 host for whatever still needs a remote dial | L0/L1 | [unchanged] | -- | existing Phase-1 runbook gate |
B.3 -- the NEW cross-DC isolation control (concern i) -- MUST precede B.4
| # | Module/artifact invoked | Layer | Tag | Depends-on | Gate |
|---|---|---|---|---|---|
| B.3.1 | Build + install the vcloud-level host isolation control (owed artifact #2): nftables artifact asserting no inter-plane/inter-DC forwarding on vcloud's own kernel; new SEC-NNN row (next-free SEC-034 per pass3 check 6); harness tests/<name> (C2, offline fixture model) |
NEW L5 artifact (SEC-010's pattern, one layer up) | [CE] | B.2.1 (vcloud host prep) | >>> HARD GATE, closes before B.4 <<< --check enumerates the live bridge set for BOTH DCs' six planes and REFUSES if fewer than the full plane count resolves; must be installed and verified before the first flat apply of EITHER per-DC root (fork-robust invariant #1, honored regardless of root shape) |
B.4 -- the flat apply (formerly outer + bootstrap-gate + inner), COLLAPSED into L1/L2
Root shape recommended (B) shared-outer + per-DC-flat roots (pass2 Section 3.1, recommendation grade, Phase-4 ratifies). One apply CYCLE per DC.
| # | Module/artifact invoked | Layer | Tag | Depends-on | Gate |
|---|---|---|---|---|---|
| B.4.0 | Shared-outer root apply: mesh triangle legs (x3, MTU 9000) + uplink NAT /24 -- already exist at vcloud level, UNCHANGED by flattening |
L0 | [unchanged] | B.3 gate closed | existing mesh/uplink module state clean |
| B.4.1 | Per-DC-flat root apply invoking modules/dc-site (owed artifact #12, new IaC composition unit): composes storage pool (collapsed from 2-per-DC to 1) + six planes (dc-planes, unchanged CIDRs/MTU/family, D-139 unaffected) + DC edge (opnsense-edge, WAN input re-pointed to attach directly to vr1_dcN_uplink NAT, no wan-bridge) + 12 role/utility node VMs (node-vm x9 + juju-01 + maas-01 + tailscale-01) |
L2 | [CE] structural; address VALUES inside these modules are [D-143] via B.1.3's lib-net literals | B.3 gate closed; B.1.1 FIT gate closed; B.1.3 lib-net literals present; B.1.4 client-VM address minted | apply succeeds (harness C1, tests/dc-site: 6-plane tree, 13-node roster incl. client VM = exactly one client-VM call, mtu=1500 tenant / 9000 underlay, site-token parameterized, no hardcoded DC literal) |
| B.4.2 | Same dc-site composition, client_vm sub-call: the new vr1-dcN-client VM (cloudinit-vm module type, ~4/8192/80, octet .8 metal-admin + D-124 transit leg per B.1.4) -- Option 1's non-hypervisor D-138 client host |
L1 | [CE], no D-143 content | B.4.1 (same apply) | client VM boots; identity confirmed live (not lib-hosts.sh/CARVE_AUX_HOSTS-tracked -- pass2 3.2 resolution) |
| B.4.3 | MAC re-measurement pass (owed artifact #8) -- 24 node MACs + 2 edge MACs move provider under the re-home; treat every MAC as unmeasured until re-pinned (hard rule 2) | L2 verify | [CE] | B.4.1 apply complete | live MAC roster captured and matches dc-site's MAC invariant (rides C1's harness, pass3 3-rides list) -- must close before B.6 trusts any MAC |
| -- | Vanished from the module set entirely (not re-homed, not a step): vvr1_dc0/vvr1_dc1 containment modules + sizing/rack-addressing/pubkey vars; the two opentofu/vr1-dcN-substrate/ roots as separate roots/states; the qemu+ssh provider dial + D-126 keys (already revoked at A.3, no successor); modules/wan-bridge + br-vr1-dcN-wan netplan; the bootstrap gate's --host-nodes duty in site-headend-install.sh |
-- | [CE] | -- | (deletion confirmed by B.4.1's module inventory containing none of these) |
B.5 -- surviving duties, re-targeted (Phase-2 recommendation-grade placement; Phase-4 ratifies)
Pass1 left this OPEN ("THE highest-leverage open item"); pass2's W2.3 measurement largely dissolves it -- carried here as pass2's recommended placement, explicitly flagged not-yet-ratified.
| # | Module/artifact invoked | Layer | Tag | Depends-on | Gate |
|---|---|---|---|---|---|
| B.5.1 | Rack-controller: RECOMMEND RETIRE the standalone Office1 enrollment entirely (pass2 4.2(i)) -- both vr1-dcN-maas-01 VMs already run region+rack (dc1 transcript-grade, dc0 functional-grade, pass2-admin-report.md check 2); NO --role rack re-enrollment step runs against the client VM. A current-day live re-measure of both DCs' primary_rack/rackd state is OWED before this is treated as settled (instrument-currency discipline) |
L3 (was; now dissolved) | [CE] | B.4.1 (maas-01 exists) | live re-measure confirms region+rack on both fresh -maas-01 VMs; A.4's decommission of the OLD vvr1-dcN rack record already closed this in Part A |
| B.5.2 | D-131 forwarder: RECOMMEND RETIRE-WITH-EVIDENCE for both DCs (pass2 4.2(ii)) -- each fresh 10.13 region sets its own BIND from the start; retirement evidence = a dig test against the fresh region's own BIND (owed artifact #13, harness C5). dc1's asymmetry (its forwarder was load-bearing pre-teardown) is a standing-RED case in C5 until this live retirement is confirmed on the new build | L3 verify (one-time evidence capture, not a standing service) | [CE] | B.4.1 (region exists), B.5.1 | dig-resolver-identity test PASSES against each fresh region's BIND (both DCs); captured into the build changelog |
| B.5.3 | Artifact-service (.4) placement -- OPEN, sizing decision, not resolved here. Neither the client VM (~80 GiB) nor vr1-dcN-maas-01 (150 GiB earmarked, no spare) fits dc0's full mirror as authored; resolved WITH NUMBERS by B.1.1's extended FIT calculator (dc0 full-mirror vs dc1 cache per D-135) |
L2/L3 storage | [CE] | B.1.1 gate (numbers), B.4.1 | a right-sized, explicitly-provisioned home is chosen and confirmed before B.6.6 (artifact-source verify) depends on it |
| B.5.4 | SEC-010 transit-leg FORWARD-drop successor (concern ii) -- endpoints RESOLVED by pass2 recommendation: client VM (DC side) + voffice1 (Office1 side); ONE extracted role-agnostic installer subcommand (out of site-headend-install.sh's node_host_setup()) installs BOTH ends (owed artifact #3) |
NEW L5 artifact, distinct from B.3 | [CE] | B.4.2 (client VM exists, its transit NIC re-measured -- NIC-naming trap: dc0 live was enp1s0, not mgmt) |
harness A3 (site-headend-install Section-8 sub-case, migrated): both-ends fixture passes; wrong-role interface-name fixture FAILS; new SEC-row disposition (possibly a SEC-010 amendment) minted |
B.6 -- MAAS enlist / commission / carve (largely unchanged mechanics; power-address value is BLOCKED)
>>> Invariant #2, the load-bearing one for this section: owed artifact #11 (power-key blast-radius mitigation) MUST close, with its harness green, before B.6.2 -- B.6.2 is the edit that a 6-item test cluster is pinned to (pass3 Section 4). A guessed URI/key value here is exactly the false-green mint the inferred-value rule (hard rule 2) exists to prevent. <<<
| # | Module/artifact invoked | Layer | Tag | Depends-on | Gate |
|---|---|---|---|---|---|
| B.6.1 | Choose the concern-(iii) power-key mitigation mechanism (owed artifact #11: command=-restricted SSH key / per-DC-scoped virsh wrapper / libvirt polkit ACL) -- required because BOTH DCs' region VMs + voffice1 now dial the SAME vcloud qemu:///system connection with no per-domain scoping (verified this pass, pass2-admin-report.md Section 2.3); root-shape (B) does NOT mitigate this (state isolation, not connection scoping) |
NEW L5 artifact | [CE] | B.4.1 (flat topology exists to design against); B.2.1 (vcloud host prep) | >>> HARD GATE <<< harness C4 (offline rendered-ACL/authorized_keys/polkit parsing) green: dc0's key reaching a dc1 domain FAILS; reaching voffice1 FAILS (mirrored both directions); new SEC-NNN row minted with the mechanism |
| B.6.2 | scripts/lib-hosts.sh VIRSH_POWER_ADDRESS_FROM_OFFICE1/_FROM_DCREGION re-derivation to vcloud's own libvirtd (whether the FROM_OFFICE1/FROM_DCREGION split survives is itself a #11 design output) |
L0 library | [both] -- D-143-shaped value change, CE-shaped mechanism dependency | B.6.1 gate closed | the SAME edit session closes A4 (dc-selector) + A5 (maas-region-power-key URI assertions) together -- editing one without the other is the named hazard H1 (a plausible-but-unenforced URI swap) |
| B.6.3 | scripts/maas-node-power.sh invocation-site/runbook literal updates -- no code change (address is $1, topology-agnostic) |
L3 | [D-143 value] | B.6.2 | every invocation-site/runbook example carries the new address |
| B.6.4 | MAAS discovers node VMs via per-machine power_type=virsh (mechanism unchanged, D-123 amendment 2026-07-20 -- the pod/vm-host mechanism was already refuted before this pass; only the VALUE re-derives) |
L3 | [D-143 value] | B.6.2, B.6.3 | discovery succeeds against the new power addresses |
| B.6.5 | Commission each node (Phase-3 Step 3); tag; nodes stay Ready; Pattern-A interface carve via scripts/dc-node-carve.sh (no code change, grep-verified zero containment hits, pure MAAS-API, <site>-parameterized) |
L3 | [unchanged] | B.6.4, B.4.3 (MACs re-measured) | commission + carve succeed; single virsh hop, no "which host can see this domain" ambiguity (the old containment-layer confusion is structurally gone) |
| B.6.6 | PXE/boot-fabric verify (Step 6); per-DC artifact-source + time-authority verify (Step 7, target host = wherever B.5.3 lands); topology consistency check (Step 8) | L3 | [D-143 value for target host] | B.6.5, B.5.3 resolved | verify steps pass against the ruled artifact-service host |
B.7 -- Juju + OpenStack bundle deploy (mechanically unchanged, host renamed)
| # | Module/artifact invoked | Layer | Tag | Depends-on | Gate |
|---|---|---|---|---|---|
| B.7.1 | Juju controller bootstrap on a tagged machine, run FROM the vr1-dcN-client VM (D-138 execution host, "never the vcloud jumphost" doctrine intact) -- same commands, renamed host from vvr1-dcN |
L4 | [both] -- mechanics [D-143] unchanged, execution-host identity [CE] changed | B.4.2 (client VM up), B.6.6 (enlist/commission/carve complete) | preflight.sh gate (incl. new P10 for B.5.4, P4 dependent on B.6.1's mitigation, P8's declared-root-list loop replacing the single hardcoded opentofu/ path) |
| B.7.2 | model/spaces setup, DC egress gate (dc-egress-check.sh, invocation-host literal re-points to the client VM), juju deploy bundle.yaml + overlays, dry-run first, mid-deploy watch |
L4 | [unchanged mechanics] | B.7.1 | Phase-4 runbook's own dry-run + watch gates |
| B.7.3 | SEC-026/028/029 credentials (re-)MINTED on the client VM -- Part A step A.3 already revoked the old copies; this is a clean mint, not a migration (pass1 check 7 reconciliation) | L4 credential | [both] | B.7.1 | ledger register rows (P5 creds-matrix) re-point to the client host class; new rows added for B.3/B.5.4/B.6.1's own key material |
| B.7.4 | vault bring-up (Step 5), IPv6 family-matrix overlay (Step 6), phase-03/04/05 steps (7-9), cloud-assert.sh --capture (Step 10), controller backup (Step 11) |
L4/L5 | [D-143 for literal addresses; mechanics unchanged] | B.7.2 | existing Phase-4 gates, unchanged content |
| B.7.5 | VERIFY-LIVE gates (Step 12): Ceph-over-v6 bind check (D-143 new literals); geneve-encap-assert.sh (owed artifact #10 -- MTU budget analytically unchanged by container-elim, live assert still owed as a NEW invocation point, not a script edit); PLUS the B.3 (a)-control's --check RE-RUN, now that both DCs' planes are actually co-resident on vcloud -- the first point in the whole sequence where the isolation claim is tested against real traffic (cloud-assert A11a periodic re-verify begins here) |
L5 | [D-143] for Ceph literals; [CE] for the (a)-control re-run and the geneve re-invocation point | B.7.4 | Ceph bind check passes; geneve-encap-assert passes; (a)-control --check passes with BOTH DCs' planes live |
B.8 -- close-out (both axes)
| # | Module/artifact invoked | Layer | Tag | Depends-on | Gate |
|---|---|---|---|---|---|
| B.8.1 | NetBox DCIM: register the new vr1-dcN-client VM + the flat node roster device records (owed artifact #9; mirrors A.9's decommission, opposite direction) |
system-of-record | [CE] | B.4.1, B.4.2 | roster fully registered in live NetBox |
| B.8.2 | Enter the container-elim [ARCH] decision record (D-123 amendment vs. new D-number; ride-alongs: D-125 bridge-in retirement, D-138 concrete-host change, D-128 amendment -- Plane 2 shrinks to MAAS/NetBox, D-122 site-down re-earn, D-124 sizing-void re-cause, D-132-addendum premises note, Stage-3 Owns/Reuse-vs-new rewrite, the client-VM .8 octet into the D-134 map) |
-- (decision-record, not a build step) | [CE] | all of Part B substantively complete | operator ruling recorded (GA-R5) -- the redeploy is NOT "done" while this is owed, per SCOPE Section 7 |
Bare-metal-test plug-in points (pre-Roosevelt, hardware specs owed "within days")
Per the operator's own framing and D-138's history (the client VM is explicitly "the D-138 Roosevelt bastion analog, rehearsed early," pass0-admin-report.md Section 4), the specs plug into sizing and provider targets inside existing steps, not a new sequence. Split by whether a step is hardware-PARAMETERIZED (re-run with new numbers/roster once specs land) or hardware-AGNOSTIC (unaffected either way):
Hardware-parameterized (specs plug in directly):
- B.1.1 -- capacity/FIT math re-derives from real host specs instead of vcloud's measured budget; the node-class roster may shrink ("a smaller set of hardware").
- B.4.1/B.4.2 --
dc-site's module bodies (planes x6, edge, node roster, client VM) are the SAME composition intended to transfer; the specs let sizing be re-derived for bare metal without changing which modules exist or their call order -- only the provider target (bare libvirt host vs vcloud-hosted VM) and concrete sizing numbers change. - B.4.3 / B.6.4 -- MAC handling: bare metal uses real NIC MACs discovered via MAAS enlistment, not libvirt-injected MACs from a tofu module -- the RE-MEASUREMENT discipline transfers, the injection mechanism does not.
- B.5.3 -- artifact-service sizing is explicitly hardware-dependent (disk on real spinning/SSD capacity vs a vcloud-hosted volume).
Hardware-agnostic (unaffected; the reusable asset IS the sequence/module shape):
- B.1.2/B.1.3 -- NetBox/lib-net addressing is pure IPAM, runs identically regardless of substrate.
- B.6.5 -- carve scripts (
dc-node-carve.shetc.) are already<site>-parameterized, pure MAAS-API; grep-verified zero containment hits (pass2 3.3). - B.7 -- Juju/bundle deploy mechanics are unchanged by substrate class (D-140 pins L4 as procedure regardless).
- The module INVOCATION ORDER itself (B.1 -> B.8) is the reusable deliverable -- the "layered module system" the operator asked this pass to produce IS the thing rehearsed early, independent of whether L1/L2 target vcloud-libvirt VMs or bare hosts.
Two controls that likely do NOT transfer as-is (flag explicitly, do not let a future session assume parity):
- B.3's (a) cross-DC isolation control is an artifact of hosting BOTH DCs' plane bridges on ONE vcloud-libvirt kernel. Genuinely separate physical hardware per DC at Roosevelt would not have this specific exposure -- the CONTROL PATTERN (host-level forwarding assertion) may still be good practice, but the gap it closes here may not exist at bare metal. Phase-4 should note this, not assume the artifact ships unchanged.
- B.6.1's power-key mitigation (#11) is a libvirt/
qemu:///system-connection-scoping problem specific to multiple VMs dialing one shared hypervisor's virsh. Bare-metal power management (IPMI/Redfish, not virsh) is a structurally different credential-scope problem; the MITIGATION DISCIPLINE (per-DC credential separation, verified by a negative test) transfers, the concrete artifact does not.
Nesting-depth honesty (carried from pass1-w3-sequencing.md Part D, not restated as new here): flat-Option-1 = vcloud (libvirt) -> node VM -> nova KVM guest, depth 2 (VR0-proven). Roosevelt bare metal = bare host -> KVM guest, depth 1. The flattening rehearses the MODULE SHAPE and the single-apply/no-bootstrap-gate WORKFLOW, not the exact nesting depth.
B.5's placement should be RE-DECIDED, not carried forward blindly, once hardware specs exist -- a bare-metal build may have a materially different answer for where MAAS-rack/ D-131/artifact-service duties land than a VM-hosted vr1-dcN-client does (this echoes pass1-w3-sequencing.md Part D verbatim; not re-derived, cited).
Sources read this session
SCOPE-AND-EXECUTION-PLAN.md (full), pass0-admin-report.md (full), pass1-admin-report.md (full), pass1-w3-sequencing.md (full), pass2-admin-report.md (full), pass3-admin-report.md (full), plus docs/design-decisions.md:8083-8182 (D-143 full ruling + owed-execution list, re-read directly this session to confirm the five owed-execution items and their exact wording). No inferred values used; every module name, owed-artifact number, and gate condition traces to the cited pass document. Items marked OPEN/RECOMMENDATION-GRADE above are stated as such, not silently upgraded to settled.