diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index 143ca49..acd99ca 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -535,6 +535,26 @@ have been 42 / 1458). Execution is a SEPARATE gated step; the verification owed is a BEHAVIOURAL large-frame test with DF set across the inter-DC path, not a reading of interface MTUs. + **R4 RULED 2026-07-27 -- exact utterance "Build a DC-aware tool; full v4 scheme + FIP now, + v6 bands after the carve (Recommended)"**, recorded as a **D-134 AMENDMENT (2026-07-27)**. + Re-measured before presenting: **D-134's bands have never existed anywhere but prose** -- + `maas admin ipranges read` returns THREE ranges cloud-wide, ALL `dynamic`, **ZERO + reserved**. The collision is QUANTIFIED: dc1 metal-admin's lowest free span is + `10.12.68.5-.99` (95 addrs), exactly the `.4-.49` utility + `.50-.99` VIP bands, against + **27 LXD units in the base bundle rising to ~55** once `dc-ha-scaleup` scales 14 apps. + Zero `10.12.*` addresses are allocated today, so this is a PRE-EMPTION, not an incident; + MAAS's exact allocation ORDER is deliberately NOT asserted. Confirmed NO VR1 path exists + -- only `site-headend-install.sh` (office1) and `phase-00-maas-standup.sh` can create an + iprange, and the latter correctly REFUSES non-VR0 ("PLANES table is DC0-hardcoded ... + refusing to plan another DC's scheme"). Ruled scope: a site-keyed reservation tool on the + `dc-mirror.sh`/`dc-rack-net.sh` pattern (which also gives D-134 an EXECUTABLE gate instead + of prose), then one gated pass for utility + VIP bands on all 12 plane subnets plus the + FIP pool `10.12.5.0-10.12.7.254` that `phase-04-network-verify.sh:100` hard-fails without. + **NEW ARCHITECTURAL CONTENT: D-134's bands were v4-only, so R2's dual-stack ruling had + left the v6 planes with NO band discipline -- the amendment establishes they inherit an + equivalent scheme.** The v6 pass is FORCED to follow the R2 carve (a range cannot be + reserved on a subnet that does not exist), not deferred by choice. Execution is a separate + gated step. - Position inside Stage 3: deploy step A EXECUTED 2026-07-19 (6/0/6 exact; convergence zero -- `docs/audit/outer-plan-20260719-postA-converged.txt`). **Deploy step B diff --git a/docs/audit/queued-rulings-20260727.md b/docs/audit/queued-rulings-20260727.md index 18e1e27..d51a85c 100644 --- a/docs/audit/queued-rulings-20260727.md +++ b/docs/audit/queued-rulings-20260727.md @@ -235,7 +235,19 @@ - **(c)** Accept the bands as unreserved for the rehearsal and rely on static assignment, recording the risk explicitly. -OPERATOR UTTERANCE: +OPERATOR UTTERANCE: **"Build a DC-aware tool; full v4 scheme + FIP now, v6 bands +after the carve (Recommended)"** -- RULED 2026-07-27. **R4 IS CLOSED.** Recorded as a +**D-134 AMENDMENT (2026-07-27)**. Re-measured before presenting, which sharpened it +considerably: the collision is QUANTIFIED -- dc1 metal-admin's lowest free span is +`.5-.99` (95 addrs), exactly the utility+VIP bands, against **27 LXD units in the base +bundle rising to ~55** with the HA overlay; zero `10.12.*` addresses are allocated today +so nothing has collided YET. Confirmed there is genuinely NO VR1 path (only +`site-headend-install.sh` and `phase-00-maas-standup.sh` can create ipranges, and the +latter correctly REFUSES non-VR0). **New architectural content: D-134's bands are +v4-only, so R2's dual-stack ruling left the v6 planes with no band discipline at all -- +the amendment establishes that they inherit an equivalent scheme.** The v6 pass is +FORCED to follow the carve (a range cannot be reserved on a subnet that does not exist), +not deferred by choice. --- diff --git a/docs/design-decisions.md b/docs/design-decisions.md index 3a21eae..07e6310 100644 --- a/docs/design-decisions.md +++ b/docs/design-decisions.md @@ -4874,6 +4874,78 @@ --- +## D-134 -- AMENDMENT (2026-07-27): the bands become ENFORCED in MAAS, via a DC-aware tool; and v6 gains band discipline + +**Status:** RULED 2026-07-27 (operator, GA-R5). Question as presented, verbatim: "R4 -- +Reserved address bands. MAAS holds ZERO reserved ipranges; dc1 metal-admin's lowest free +span is .5-.99, exactly the D-134 utility+VIP bands, and the dc1 deploy needs ~55 LXD +addresses. No VR1 tool exists to create reservations (phase-00 refuses non-VR0), and +D-134's bands are v4-only so the newly-ruled v6 carve has no band discipline. What scope?" +Options presented: (a) build a DC-aware tool, full v4 scheme + FIP now, v6 bands after the +carve; (b) one-off API calls now, no tool; (c) minimum viable, VIP band only. Operator +selection, exact utterance: **"Build a DC-aware tool; full v4 scheme + FIP now, v6 bands +after the carve (Recommended)"**. + +**THE DEFECT: D-134's bands have never existed anywhere but prose.** Measured 2026-07-27: +`maas admin ipranges read` returns exactly THREE ranges cloud-wide and ALL THREE are +`type=dynamic` -- there are **ZERO reserved ranges anywhere in this MAAS**. The band table +in the 2026-07-23 amendment above has been, since it was written, a document. + +**THE COLLISION IS QUANTIFIED, not hypothetical.** MAAS's own +`subnet unreserved-ip-ranges` for dc1 metal-admin (subnet 11, `10.12.68.0/22`) reports its +free spans as: +``` +10.12.68.5 - 10.12.68.99 (95 addrs) <- the ENTIRE utility + VIP band +10.12.68.103 - 10.12.68.119 (17) <- gaps between node statics +10.12.68.122 - 10.12.68.149 (28) +10.12.68.154 - 10.12.68.200 (47) +10.12.68.255 - 10.12.71.254 (768) +``` +The LOWEST free span is `.5-.99`, i.e. precisely the `.4-.49` utility band and the whole +`.50-.99` VIP band. Against that, the dc1 bundle places **27 LXD units** in base form and +**~55** once `overlays/dc-ha-scaleup.yaml` scales 14 applications -- every one needing an +address MAAS must allocate. The VIP band is where the 33 per-DC VIPs live. +NOT ASSERTED (and deliberately so): MAAS's exact allocation ORDER. What is asserted is +that ~55 allocations will be drawn from a pool whose lowest 95 slots are the VIP band, with +nothing reserving it. Zero `10.12.*` addresses are allocated today, so nothing has collided +yet -- this is a pre-emption, not an incident. + +**NO VR1 PATH EXISTS.** Only two scripts in the tree can create an iprange: +`scripts/site-headend-install.sh` (office1-only) and `scripts/phase-00-maas-standup.sh`, +which REFUSES for any non-VR0 DC -- measured at `:136`, "FAIL: PLANES table is +DC0-hardcoded ... refusing to plan another DC's scheme". That refusal is CORRECT behaviour +(it is the cross-DC mixing guard `lib-net`'s selector exists to prevent); the gap is that +nothing replaced it for VR1. D-058 remains the single authority for WHAT gets reserved; +this amendment is about the VR1 mechanism and its enforcement. + +**RULED SCOPE:** +1. Ship a **site-keyed reservation tool**, following the established + `dc-mirror.sh` / `dc-rack-net.sh` / `dc-cache-proxy.sh` pattern (`check` / `install` + per site, harnessed, fails closed). It is needed regardless -- no VR1 path exists -- and + it is Roosevelt-transferable, since per-DC address reservation is a real bare-metal need. + It also gives D-134 an EXECUTABLE gate instead of prose, which is what a `check` arm + buys: today nothing can detect that the bands are unenforced. +2. One gated pass for the **full v4 scheme**: utility `.4-.49` and VIP `.50-.99` on all 12 + DC plane subnets, plus the **FIP pool** `10.12.5.0-10.12.7.254`, whose absence + `scripts/phase-04-network-verify.sh:100` already hard-fails on. +3. **v6 bands follow as a second pass with the same tool, after the R2 carve lands.** This + is FORCED SEQUENCING, not a deferral: a reserved range cannot be created on a subnet + that does not yet exist, and the v6 plane subnets are not in MAAS. + +**NEW ARCHITECTURAL CONTENT -- v6 band discipline.** D-134's table is v4-only. R2's +dual-stack ruling makes the 33 VIPs dual-family, so the v6 subnets need equivalent +protection or the same collision reappears in the other family. This amendment establishes +that **the v6 planes inherit an equivalent band discipline**, mirroring the v4 scheme's +intent (a reserved low band for utility/VIP use, node statics above it). The exact v6 octet +mapping is NOT ruled here -- it lands with the carve, and mirroring the v4 host-part layout +is the obvious mechanical default rather than a fresh design question. + +**Execution is a SEPARATE gated step, not authorised by this amendment.** Standard delivery +discipline applies: the tool ships with its `tests//run-tests.sh` green, gauntlet ALL +GREEN, repo-lint 0-fail, and a changelog entry carrying a revert. The reservation pass +itself is an operator-gated live MAAS mutation across 12 subnets and is not batched with +the tool's delivery. + ## D-135: ADOPTED (AMENDED 2026-07-24) -- VR1 per-DC artifact mirror realization (D-107 build-out, staged) [ARCH] **Status:** ADOPTED 2026-07-23 (Stage 4, branch dc-dc-stage4-phase3-maas-deploy). Two