diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index 4999b45..6f63b0a 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -2481,6 +2481,34 @@ half is complete and unaffected** (each DC's OOB `/64` comes from its own `/48`), **and the step-1 push is v6-only, so it is NOT blocked by this.** **VPN (`:e0`) is the SAME omission, surfaced alongside OOB, named in neither utterance, and left OPEN rather than folded in.** + **>>> CONFORMANCE VERIFIED AGAINST THE SOLIDIFIED SPECS, AND THE DEPLOY INPUT FAILS IT. + Capture: `docs/audit/d139-conformance-dc0-20260801.txt` (83 lines). <<<** Every ruled row of + D-139 ruling A, ruling B, the "B plus C" narrowing and the OOB amendment was compared to the + ARTIFACT -- live MAAS subnets, apex prefixes/ip-addresses, the deploy overlays -- never to + another document. **THE BLOCKER, MEASURED: `overlays/vr1-dc0-vips.yaml` carries an R2 + dual-family SEXTET per service across 13 services, and 26 of its 39 v6 VIP legs are ULA** -- + 13 on `fd50:840e:74e2:220::` (metal-admin) and 13 on `fd50:840e:74e2:221::` (metal-internal), + with only the 13 `2602:f3e2:f02:11::` provider-public legs already GUA. **Those 26 legs are + EXACTLY the 26 dependent ip-addresses the step-1 dry run reports inside the retiring ULA + `/64`s -- the same objects, confirmed by description (`VIP keystone metal-admin v6 + (vr1-dc0)`), not by matching counts.** CONSEQUENCE: **deploying after steps 1-3 alone would + configure 26 VIP legs on prefixes ruling B RETIRES, while their GUA replacements + (`f02:20::/64`, `f02:21::/64`) exist in apex and MAAS but appear NOWHERE in the deploy + input.** The overlay must be re-rendered onto GUA before Step 4, or the cloud is deployed + onto retired addressing. This is the measured form of the step 4-6 coupling flagged at the + ordering ruling and is NOT settled by it. **CORRECTION TO THIS SESSION'S OWN NEAR-RETRACTION: + a first grep of that overlay was `head`-truncated and showed only the GUA legs, which would + have retracted a correct finding.** The full read is the authority. + **REST OF THE CONFORMANCE RESULT:** provider-public conforms in both families across apex, + MAAS and the node `br-ex`; all nine role nodes hold six v6 statics matching MAAS (G19, live); + ruling B is RULED-BUT-NOT-BUILT for every plane except provider-public (which pre-dates + D-139); the four ruled-REMOVED v4 prefixes are deliberately still present under "B plus C" + but sit in the apex `status=active` citing only **D-101** -- the decision D-139 amended -- + with no D-139 annotation. **ALSO MEASURED: `scripts/lib-net.sh` contains ZERO IPv6** (0 + v6-shaped lines), so D-139 step 4's "update `lib-net.sh`'s v6 arm" has no arm to update -- + one must be AUTHORED. And **no gate compares D-139's family matrix or GUA table to any + artifact**; `dc-node-v6-verify.sh`'s own header says it asserts NIC-against-MAAS and + explicitly NOT against the ruled table, so this drift class has no detector. **STILL OWED BEFORE THE DEPLOY, in ruled order:** D-139 step 1 (apex CREATE-only push, `netbox/d139-gua-carve.py --dc vr1-dc0 --commit`; tool built, independently reviewed, dry-run byte-identical, `--commit` never yet passed), step 2 (MAAS GUA `/64`s alongside the diff --git a/docs/audit/d139-conformance-dc0-20260801.txt b/docs/audit/d139-conformance-dc0-20260801.txt new file mode 100644 index 0000000..4f3747f --- /dev/null +++ b/docs/audit/d139-conformance-dc0-20260801.txt @@ -0,0 +1,83 @@ +d139-conformance-dc0-20260801.txt +================================== +Conformance of the vr1-dc0 DEPLOY INPUTS and LIVE SUBSTRATE against the specs +solidified 2026-07-31/08-01: D-139 ruling A (family matrix), ruling B (GUA +addressing), the 2026-08-01 "B plus C" narrowing, and the 2026-08-01 OOB +amendment. Read-only. Host: vcloud + voffice1. No deploy has occurred. + +METHOD: each ruled row was compared to the ARTIFACT (live MAAS subnets, apex +prefixes/ip-addresses, the deploy overlays), never to another document. This is +the "RULED IS NOT BUILT -- check the artifact" test. + +-------------------------------------------------------------------------------- +A. RULING A -- family matrix vs live MAAS (dc0 region, profile vr1-dc0-region) +-------------------------------------------------------------------------------- +plane ruled family v4 in MAAS v6 in MAAS verdict +provider-public dual-stack 10.12.4.0/22 Y 2602:f3e2:f02:10::/64 CONFORMS (v6 already GUA) +metal-admin dual-stack 10.12.8.0/22 Y fd50:840e:74e2:220::/64 v4 ok; v6 is ULA -> step 2 +metal-internal IPv6-only 10.12.12.0/22 Y fd50:...:221::/64 v4 PRESENT (see note B) +data-tenant IPv6-only 10.12.16.0/22 Y fd50:...:230::/64 v4 PRESENT (see note B) +storage IPv6-only 10.12.32.0/22 Y fd50:...:240::/64 v4 PRESENT (see note B) +replication IPv6-only 10.12.36.0/22 Y fd50:...:250::/64 v4 PRESENT (see note B) +lb-mgmt IPv6-only NEW - - - NOT BUILT, either family (step 5) +oob dual-stack NEW - - - NOT BUILT, either family + +NOTE B -- the four v4 prefixes are NOT a defect: the 2026-08-01 "B plus C" ruling +narrowed ruling A's v6-only EXECUTION to a storage+replication experiment, and step 7 +(v4 removal) is out of the execution list and gated on the unmeasured `network-get` +question. They are RULED-REMOVED and DELIBERATELY still present. What IS worth +recording: all four sit in the apex as status=active with descriptions citing only +D-101 -- the decision D-139 amended -- and carry NO D-139 annotation anywhere. + +-------------------------------------------------------------------------------- +B. RULING B -- GUA carve vs apex and MAAS +-------------------------------------------------------------------------------- +apex prefixes scoped vr1-dc0: 13 v6 (4 GUA + 9 ULA), 8 v4. +GUA present: 2602:f3e2:f02::/48, :10::/60, :10::/64, :11::/64 (provider-public only, + and it PRE-DATES D-139 -- carved under D-101/D-111) +GUA absent: :20::/60 :20::/64 :21::/64 :30::/60 :30::/64 :40::/60 :40::/64 + :50::/60 :50::/64 :80::/60 :80::/64 :f0::/60 :f0::/64 = the 13 CREATE rows +ULA /48 retired for VR1: NOT retired. 9 prefixes live, holding 26 dependent ip-addresses. +VERDICT: ruling B is RULED-BUT-NOT-BUILT except for provider-public. Steps 1-2 close it. + +-------------------------------------------------------------------------------- +C. >>> THE DEPLOY INPUT DOES NOT CONFORM, AND THIS IS THE BLOCKER <<< +-------------------------------------------------------------------------------- +overlays/vr1-dc0-vips.yaml carries an R2 dual-family SEXTET for each of 13 services: + vip: "10.12.4.50 10.12.8.50 10.12.12.50 2602:f3e2:f02:11::50 \ + fd50:840e:74e2:220::50 fd50:840e:74e2:221::50" +Counted across the file: 13x 2602:f3e2:f02:11:: (GUA, provider-public VIP) + 13x fd50:840e:74e2:220:: (ULA, metal-admin) + 13x fd50:840e:74e2:221:: (ULA, metal-internal) +So 26 of the 39 v6 VIP legs are ULA -- and they are EXACTLY the 26 dependent +ip-addresses the step-1 dry run reports inside the retiring ULA /64s. The two sets +are the same objects, confirmed by description ("VIP keystone metal-admin v6 (vr1-dc0)"). + +CONSEQUENCE: deploying after steps 1-3 alone would configure 26 VIP legs on prefixes +that ruling B RETIRES, while their GUA replacements (:20::/64, :21::/64) exist in the +apex and MAAS but appear NOWHERE in the deploy input. The overlay must be re-rendered +onto GUA before Step 4, or the cloud is deployed onto retired addressing. + +This is the measured form of the step 4-6 coupling flagged at the ordering ruling. It +is NOT settled by that ruling, which named steps 1-3 only. + +-------------------------------------------------------------------------------- +D. OTHER MEASURED GAPS +-------------------------------------------------------------------------------- +1. scripts/lib-net.sh contains ZERO IPv6 (0 v6-shaped lines). D-139 step 4 says + "update lib-net.sh's v6 arm" -- there is no v6 arm to update; one must be AUTHORED. +2. No gate compares D-139's family matrix or GUA table to any artifact. Only three + files mention D-139, and dc-node-v6-verify.sh's own header states it asserts + NIC-against-MAAS and explicitly NOT against D-139's ruled table. +3. OOB's v4 half (10.12.60.0/22) has no per-DC split -- UNRULED, deliberately not + inferred. The v6 half is complete and in the tool. +4. VPN (:e0) remains omitted from the carve; VR0 and Willamette both hold it. + +-------------------------------------------------------------------------------- +E. WHAT IS CONFORMANT TODAY +-------------------------------------------------------------------------------- +- provider-public, both families, apex + MAAS + node br-ex (2602:f3e2:f02:10::150). +- All 9 role nodes hold 6 v6 statics each, matching MAAS exactly (gate G19, live). +- The carve TOOL now matches the ruled table incl. OOB: dry run CREATE 13 | EXISTS 3 + | RETIRE-REPORT 9, both oob rows present, nothing written. +- Apex prefix count 139, unchanged; --commit has never been passed.