GitBucket
Changelog -- 2026-07-23 -- Stage 4 open: discovery + D-133 carve ruling
Session scope: open Stage 4 (Phase 3, MAAS enlist/commission/deploy per DC) on branch dc-dc-stage4-phase3-maas-deploy off post-merge main. Bootstrap ran clean (pull up-to-date at bff71d4; repo-lint 0 fail / 1 legacy warn; ledger-scan reconciled -- 12 open SEC rows, D next-free 133). No cloud mutation this session yet; everything below is read-only measurement + repo records.
Item 1 -- Stage 4 OPENED: precondition + discovery (read-only), captured
- Branch
dc-dc-stage4-phase3-maas-deploycreated offmain(bff71d4). - Runbook Step 0 precondition PASS: both DC rack controllers enrolled (vvr1-dc0
7chphy, vvr1-dc1nmpcq4). - Step 2 discovery complete for BOTH DCs, all read-only, captured to
docs/audit/stage4-discovery-20260723.txt: 9 nodes per DC, ALL Ready, power=virsh; dc0 = boot fabric-4 / MACs 52:54:00:, dc1 = fabric-142 / pinned 52:54:01:d1:; zone/pooldefaulteverywhere (no zone/pool convention exists -- fabric + MAC prefix is the grouping signal). Also captured: one dc0 node's full physical NIC list (6 flat per-plane NICs),default_distro_series=noble, and the synced boot-resources list (noble ONLY -- no jammy images on the region). - Runbook-vs-reality deltas recorded in CURRENT-STATE (the runbook predates Stage 3's execution): Step 3 commissioning already satisfied; carve comes BEFORE deploy per the runbook's own Ready-state sequencing note; gap #6 (pod-discovery landing status) is moot -- the pod path was refuted 2026-07-20.
- Revert:
git branch -D dc-dc-stage4-phase3-maas-deploy(after moving off it); deletedocs/audit/stage4-discovery-20260723.txt; revert the CURRENT-STATE Stage-4 bullet. No live state was touched.
Item 2 -- D-133 ADOPTED: flat per-NIC carve (VR1); hardware-faithful NIC topology next deployment
- New entry
docs/design-decisions.mdD-133 [ARCH], Status ADOPTED 2026-07-23, operator utterance quoted verbatim per GA-R5 ("Fine, keep it flat but on the next deployment we need to build the VMs with exact hardware duplicated networking so we can work out any bonding/trunking kinks."). - Part 1: VR1 DC nodes carve every plane FLAT on its dedicated NIC; no VLAN-103 stack in VR1 (supersedes the D-052-era Pattern A shape for VR1 DC nodes only; VR0 untouched).
- Part 2 (pinned to next deployment): node VMs duplicate target hardware's exact NIC topology (bond members, trunks) -- composes with D-132.
- Affected-surfaces list recorded IN the entry (buildout-design VID-103 text, workflow Stage 4 row, phase3 runbook Step 5 tree, lib-net vr1-dc0 arm's inherited METAL_INTERNAL_VID) -- queued as this stage's DOCFIX/delivery work, not silently edited.
- CURRENT-STATE section 1 updated in the same commit (GA-R1 C1): Stage 4 OPEN bullet with discovery facts + the open decision points (deploy OS series, octet plan, mirror gap #5, tag shape).
- Revert: remove the D-133 block from design-decisions.md and the Stage-4 bullet from CURRENT-STATE.md (single commit;
git revert <sha>).
Item 3 -- D-134 ADOPTED: per-role octet bands for VR1 DC node statics
- New entry
docs/design-decisions.mdD-134 [ARCH], ADOPTED 2026-07-23. Sequence per GA-R5: the flat .40-.48 proposal was presented and REJECTED ("Different band"); operator directed "Per role bands with headroom. Give me a recommendation"; the recommended band table was presented with measured collision checks (bundle VIPs .50-.60 grep, 10.12.12.4, FIP pool, D-120 dynamic range) and adopted ("Adopt as recommended"). - Bands: .1-.9 infra (.4-.9 utility-reserved), .10-.19 control, .20-.49 compute, .50-.99 formal VIP band, .100-.200 dynamic (D-120), .201-.254 storage. One octet per node across all six planes, both DCs; VR1 assignments control .10-.12 / compute .20-.21 / storage .201-.204 keyed by tofu node name via pinned boot MAC.
- CURRENT-STATE Stage-4 bullet updated in the same commit (octet plan RULED; carve now unblocked on D-133 + D-134).
- Revert: remove the D-134 block + the CURRENT-STATE bullet edit (
git revert <sha>).