diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index 3340c7b..a44b96a 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -2142,7 +2142,23 @@ `docs/audit/queued-findings-20260803-stage5-deploy-ovn.txt` (4 FIRST SURFACE: the red gate, gitignored settings.local.json growth 310->313, the voffice1 lag, the live resume snapshot). **NEXT SESSION:** escalate LP #2044324 + decide accept-degraded vs the unverified `os-*-network` - avenue; reconcile provider-bundle-check to D-141; then phase-03 core verify. + avenue; then phase-03 core verify. (The sweep-F1 provider-bundle-check reconcile was DONE + 2026-08-03 -- see the addendum below.) + **>>> ADDENDUM 2026-08-03 (post-bookend, harness reconcile) -- SWEEP F1 CLOSED, GAUNTLET GREEN + AGAIN. <<<** `tests/provider-bundle-check/run-tests.sh` re-pointed to the v4-only deploy input + under D-141: T19's assertion REPLACED with the v4-only invariant (`0 dual-family` on the real + input); T21/T25/T45 re-pointed to a NEW synthetic all-GUA `dual.yaml` fixture (v6 legs = the + MEASURED pre-revert dual-family legs, `3e691cd^`, present in the current apex) so the + dual-family PASS/refusal controls survive for D-141 rule-3 promotion -- re-pointed, NOT deleted + (the checker's dual-family path is still live code). `scripts/provider-bundle-check.py` + UNCHANGED (family-agnostic: a vip is a v4 triple OR a dual-family sextet). Case count unchanged + 55->55. Captured this commit: `bash scripts/run-tests-all.sh` -> **GAUNTLET: ALL GREEN (98 + harnesses)** (was `1/98 FAIL`); `bash tests/provider-bundle-check/run-tests.sh` -> **55/55 ALL + PASS**; repo-lint 0 fail / 1 legacy warn. Body: + `docs/changelog-20260803-provider-bundle-check-d141-reconcile.md`. Two items LOGGED-not-fixed + there (also appended to the close sweep): the `DUAL6` constant still grades T22/T23 against the + D-139-deprecated ULA family, and the generated `vr1-dc0-vips.yaml` header still describes + dual-family over v4-only lines (renderer/values divergence). **>>> PRE-VAULT-INIT END STATE REACHED; VAULT PREFLIGHT PASSES `PROCEED` 2026-08-03. <<<** After the stall fix, the model converged: `scripts/phase-02-vault-preflight.sh vr1-dc0` (staged + sha256-verified on the rack, `90910dfb`) reports **PROCEED** -- mysql cluster 3/3 diff --git a/docs/audit/queued-findings-20260803-stage5-deploy-ovn.txt b/docs/audit/queued-findings-20260803-stage5-deploy-ovn.txt index 953ebb4..37c8dc4 100644 --- a/docs/audit/queued-findings-20260803-stage5-deploy-ovn.txt +++ b/docs/audit/queued-findings-20260803-stage5-deploy-ovn.txt @@ -82,3 +82,30 @@ - Nested-quote / paren shell errors bit several remote one-liners (harmless, re-run). - Guard hook blocked two commit MESSAGES (kill-controller, vault-init command names) -- correct conservative behaviour; reworded via a message file. + +-------------------------------------------------------------------------------------- +AMENDED 2026-08-03 (post-bookend, harness-reconcile session) -- F1 CLOSED + 2 follow-ons +-------------------------------------------------------------------------------------- +F1 CLOSED: provider-bundle-check reconciled to D-141 (v4-only deploy input). T19 assertion + REPLACED with the v4-only invariant; T21/T25/T45 re-pointed to a new all-GUA dual.yaml + fixture (checker unchanged). Gauntlet ALL GREEN (98). Body: + docs/changelog-20260803-provider-bundle-check-d141-reconcile.md. + +FN1 (LOGGED, not fixed). tests/provider-bundle-check DUAL6 constant (run-tests.sh:61) uses + the ULA family fd50:840e:74e2:220::/221:: for the metal-admin/internal v6 legs -- the + family D-139 step 6 DEPRECATED (do-not-allocate under D-141). It still validates only + because step 6 deprecated rather than deleted those /64s and _apex_v6_bands ignores + NetBox status. So negative controls T22/T23 grade against a retired family while the new + dual.yaml (FN closed) is on GUA -- the harness holds two notions of "valid dual-family". + Fix: re-pin DUAL6 to GUA + assert the apex marks the ULA /64s deprecated. Operator to rule. + +FN2 (LOGGED, not fixed). overlays/vr1-dc0-vips.yaml GENERATED header still describes + dual-family legs ("each vip carries the three v4 legs THEN the three v6 legs") over + v4-only VIP lines -- a renderer/render-values divergence from the D-141 revert. Fix is in + scripts/render-dc-overlays.py + render/values, not the harness. + +FN3 (LOGGED, watch item, advisor-flagged). The dual.yaml builder skips any app whose vip is + not exactly 3 tokens, so if the overlay is ever re-rendered dual-family, the builder + silently yields good.yaml unchanged and T21/T45 keep passing while asserting nothing new + ("a clean zero deserves suspicion"). When D-141 rule-3 promotes v6, make the builder + ASSERT it appended legs (or drive dual.yaml from the rendered dual overlay directly). diff --git a/docs/changelog-20260803-provider-bundle-check-d141-reconcile.md b/docs/changelog-20260803-provider-bundle-check-d141-reconcile.md new file mode 100644 index 0000000..e2749dc --- /dev/null +++ b/docs/changelog-20260803-provider-bundle-check-d141-reconcile.md @@ -0,0 +1,108 @@ +# Changelog -- 2026-08-03: reconcile provider-bundle-check harness to D-141 + +Session scope: close the RED gauntlet the 2026-08-03 deploy session left at its bookend +(`docs/audit/queued-findings-20260803-stage5-deploy-ovn.txt` **sweep F1**) -- +`run-tests-all` 1/98 FAIL on `provider-bundle-check`, 4 dual-family cases. Stage 5 remains +OPEN; nothing here opens or closes a stage. No change to `scripts/provider-bundle-check.py` +-- the checker is family-agnostic (a vip is a v4 triple OR a dual-family sextet); this is a +HARNESS reconcile only. + +--- + +## Item 1 -- sweep F1: provider-bundle-check re-pointed to the v4-only deploy input (D-141) + +**The defect.** On 2026-08-03 the dc0 VIP overlay was reverted to IPv4-only under **D-141** +(`3e691cd`, "revert dc0 VIP overlay to IPv4-only; v6 GUA block RETAINED as reserved") -- v6 +GUA is now `reserved`-until-capable in the NetBox apex, not deployed. A built-surface change +shipped WITHOUT its companion harness update: four `tests/provider-bundle-check` cases still +asserted the REAL deploy input is dual-family, so `run-tests-all` closed the day RED at +`1/98 FAIL -- provider-bundle-check`. This is the repo's own "remediating a finding turns the +harness red -- REPLACE the assertion with the new invariant, never delete it to go green" +class. + +The four cases (measured `RESULT: PASS=51 FAIL=4`): +- **T19** `13 clustered VIP(s) ... 13 dual-family` on `good.yaml` -- the checker now reports + `(0 dual-family)` on the v4-only input. +- **T21**, **T45** the same `13 dual-family` PASS assertion on `good.yaml`. +- **T25** dual-family + unreadable apex REFUSES (rc=2) on `good.yaml` -- a v4-only bundle + needs no apex, so it returned rc=0 (that path is T26). + +**The reconcile (re-point, never delete -- the checker's dual-family logic is still live code +and D-141 rule 3 will promote v6, so its coverage MUST be preserved):** + +- **New fixture `dual.yaml`** built in the fixture block: `good.yaml`'s v4 triples with the + three v6 legs appended, the v6 host part textually mirroring the v4 octet. This is the + shape D-141 rule-3 promotion RESTORES. The v6 prefixes are the **MEASURED all-GUA legs of + the pre-revert dual-family deploy input** (`git show 3e691cd^:overlays/vr1-dc0-vips.yaml`): + provider `2602:f3e2:f02:11::/64`, metal-admin `2602:f3e2:f02:20::/64`, metal-internal + `2602:f3e2:f02:21::/64` -- all present in the current apex (D-139 step 6, 2026-08-02). + **Deliberately NOT the module `DUAL6` constant**, whose `fd50:` admin/internal legs are the + **ULA family D-139 DEPRECATED** (do-not-allocate under D-141) -- see Item 2. +- **T19 REPLACED** with the new invariant: the real dc0 deploy input is v4-only under D-141, + asserting `13 clustered VIP(s) ... (0 dual-family)` on `good.yaml`. The comment records the + re-point-back-to-dual-family instruction for when v6 is promoted. +- **T21, T45 RE-POINTED** to `dual.yaml` (assertion unchanged: `(13 dual-family)`), preserving + the dual-family full-count PASS controls (9b absence / 9a declare positive controls) on the + fixture promotion restores rather than on the now-v4-only real input. +- **T25 RE-POINTED** to `dual.yaml`, preserving the "could not look is never nothing there" + apex-refusal control on a live dual-family input. + +**Failing-direction proved** (repo rule: prove the assertion CAN fail, do not infer it): the +new T19 regex `13 clustered VIP\(s\).*\(0 dual-family\)` matches the v4-only `good.yaml` line +and does NOT match `dual.yaml`'s `(13 dual-family)` line. `dual.yaml` verified in both +directions before wiring: default apex -> rc=0 `(13 dual-family)`; `APEX_RECORD=/nonexistent` +-> rc=2 refusal. + +**Case count unchanged: 55 -> 55** (pure re-point, no case added or dropped). Post-change: +`RESULT: PASS=55 FAIL=0 / ALL PASS`. + +- Changed: `tests/provider-bundle-check/run-tests.sh` -- add the `dual.yaml` fixture builder + (argv[6]); re-point T19 (assertion replaced), T21, T25, T45; correct the now-vacuous + `v4only.yaml` comment (see Item 3). +- Verified: `bash tests/provider-bundle-check/run-tests.sh` -> **55/55 ALL PASS**; full + `bash scripts/run-tests-all.sh` -> **ALL GREEN (98)** (captured; was `1/98 FAIL`); + `repo-lint` 0 fail. ASCII/LF clean. +- **Revert:** `git checkout ^ -- tests/provider-bundle-check/run-tests.sh`. The + gate returns to RED against the current v4-only overlay, which is the pre-fix state. + +## Item 2 -- LOGGED, not fixed: `DUAL6` grades T22/T23 against the DEPRECATED ULA family + +The module constant `DUAL6` (`run-tests.sh:61`) uses `fd50:840e:74e2:220::` / `:221::` for +the metal-admin / metal-internal v6 legs. Those are the **ULA family D-139 step 6 DEPRECATED** +(2026-08-02; `deprecated` -> do-not-allocate under **D-141**'s status table). It still +validates only because step 6 deprecated rather than DELETED those prefixes and +`_apex_v6_bands` resolves per-leg family without reading NetBox status. So the negative +controls T22/T23 (wrong-`/64`, wrong host-part) are graded against a retired family, and with +Item 1's `dual.yaml` on GUA the harness now holds TWO notions of "valid dual-family vip". +**Not fixed here** (out of this reconcile's scope; would touch cases written for a different +invariant). Recommend re-pinning `DUAL6` to the GUA legs and asserting the apex marks the ULA +`/64`s `deprecated` -- operator to rule. Recorded on the close sweep as **FN1** +(`docs/audit/queued-findings-20260803-stage5-deploy-ovn.txt`, AMENDED block). + +## Item 3 -- corrected comment: the `v4only.yaml` twin is byte-identical to `good.yaml` today + +Under D-141 `good.yaml` is itself v4-only, so the `v4only.yaml` builder is a no-op TODAY and +the old comment's rationale ("mutate this instead of good.yaml so the v4-shaped cases do not +trip the prefer-ipv6 coupling check first") is vacuous. The comment is corrected to state the +current identity AND why the builder is RETAINED: if D-141 rule-3 promotion re-renders the +overlay dual-family, `good.yaml` becomes a sextet again and the twin AUTOMATICALLY re-diverges +to the v4 legs T5/T8/T26/T28 need. No case restructured -- comment only. Leaving a comment +asserting a distinction that no longer exists is a trap for the next session; this is D-141 +fallout, so it belongs in this reconcile. + +## Item 4 -- LOGGED, not fixed: generated overlay header still says "DUAL-FAMILY per R2" + +`overlays/vr1-dc0-vips.yaml`'s GENERATED header block still describes dual-family legs +("each vip carries the three v4 legs THEN the three v6 legs") over v4-only VIP lines -- +a renderer/values divergence from the D-141 revert. Out of scope (renderer + `render/values` +work, not the harness). Recorded on the close sweep as **FN2**. + +## Item 5 -- LOGGED watch item (advisor-flagged): the `dual.yaml` builder can silently no-op + +The `dual.yaml` builder skips any app whose vip is not exactly 3 tokens. That is correct today +(the overlay is v4-only), but if D-141 rule-3 promotion re-renders the overlay dual-family, +`good.yaml` is already a sextet and the builder yields it unchanged -- T21/T45 would keep +passing while asserting nothing new (the "clean zero deserves suspicion" shape). At promotion, +make the builder ASSERT it appended legs, or drive `dual.yaml` from the rendered dual overlay +directly. Paired with the re-point-back instruction already written into T19's comment. +Recorded on the close sweep as **FN3**. diff --git a/tests/provider-bundle-check/run-tests.sh b/tests/provider-bundle-check/run-tests.sh index 72572fa..af112f4 100644 --- a/tests/provider-bundle-check/run-tests.sh +++ b/tests/provider-bundle-check/run-tests.sh @@ -30,7 +30,7 @@ # -- is base + overlays/vr1-dc0-vips.yaml. The bare base is no longer a deploy # input at all, and T31 asserts exactly that rather than leaving it untested. python3 - "$REPO/bundle.yaml" "$REPO/overlays/vr1-dc0-vips.yaml" \ - "$TMP/pristine.yaml" "$TMP/good.yaml" "$TMP/v4only.yaml" <<'PY' + "$TMP/pristine.yaml" "$TMP/good.yaml" "$TMP/v4only.yaml" "$TMP/dual.yaml" <<'PY' import sys, yaml, copy base = yaml.safe_load(open(sys.argv[1])) ovl = yaml.safe_load(open(sys.argv[2])) @@ -42,11 +42,13 @@ # deploy input needs no injection any more -- good == pristine. The case that used # to assert the .62 gap is RE-POINTED below, not deleted. yaml.safe_dump(base, open(sys.argv[4], "w")) -# A V4-ONLY twin: every vip truncated to its three v4 legs and prefer-ipv6 dropped, -# TOGETHER (dropping one alone IS the L3-9 defect). The v4-shaped cases mutate this -# instead of good.yaml, so they still exercise the band / octet-uniqueness / -# apex-independence invariants they were written for, rather than tripping the -# prefer-ipv6 coupling check first and never reaching them. +# A V4-ONLY twin: every vip truncated to its three v4 legs, prefer-ipv6 dropped. +# UNDER D-141 (2026-08-03) the dc0 VIP overlay was itself REVERTED to IPv4-only (the +# v6 GUA block reserved-until-capable in the apex), so `good.yaml` is ALREADY v4-only +# and this twin is byte-identical to it today. The builder is RETAINED, not removed: +# if D-141 rule-3 promotion re-renders the overlay dual-family, `good.yaml` becomes a +# sextet again and this twin AUTOMATICALLY re-diverges to the three v4 legs the +# v4-shaped cases (T5/T8/T26/T28) need -- a stable v4 base independent of good's family. v4 = copy.deepcopy(base) for n, spec in v4["applications"].items(): o = (spec or {}).get("options") or {} @@ -54,6 +56,25 @@ o["vip"] = " ".join(str(o["vip"]).split()[:3]) o.pop("prefer-ipv6", None) yaml.safe_dump(v4, open(sys.argv[5], "w")) +# A DUAL-FAMILY fixture: good.yaml's v4 triples with the three v6 legs appended, the +# v6 host part textually mirroring the v4 octet. This is the shape D-141 rule-3 +# promotion RESTORES. The v6 prefixes are the MEASURED all-GUA legs of the pre-revert +# dual-family deploy input (commit 3e691cd^ overlays/vr1-dc0-vips.yaml): provider +# 2602:f3e2:f02:11::/64, metal-admin 2602:f3e2:f02:20::/64, metal-internal +# 2602:f3e2:f02:21::/64 -- all present in the current apex (D-139 step 6, 2026-08-02). +# NOT the module DUAL6 constant, whose fd50: admin/internal legs are the ULA family +# D-139 DEPRECATED (do-not-allocate under D-141) -- flagged in the changelog. Because +# the dc0 deploy input is v4-only under D-141, the dual-family PASS controls (T21/T45) +# and the apex-refusal control (T25) validate against THIS synthetic input, not good. +PROV, ADM, INT = "2602:f3e2:f02:11::", "2602:f3e2:f02:20::", "2602:f3e2:f02:21::" +dual = copy.deepcopy(base) +for n, spec in dual["applications"].items(): + o = (spec or {}).get("options") or {} + v = o.get("vip") + if v and len(str(v).split()) == 3: + legs = str(v).split(); octet = legs[0].split(".")[-1] + o["vip"] = " ".join(legs + [PROV + octet, ADM + octet, INT + octet]) +yaml.safe_dump(dual, open(sys.argv[6], "w")) PY # A valid dual-family (R2 dual-stack) VIP for keystone: the three v4 legs plus the # three v6 legs, host part mirroring the v4 octet per the 2026-07-27 ruling. The @@ -229,9 +250,14 @@ "T18 hacluster check goes GREEN once the ruled VIP lands" "$TMP/good.yaml" # ---- R2 dual-stack: VIP arity, family coupling, and the apex-derived v6 bands ---- -# T19 a valid dual-family sextet PASSES and is counted as dual -run 0 '13 clustered VIP\(s\).*13 dual-family' \ - "T19 every app is dual-family in the real deploy input" "$TMP/good.yaml" +# T19 RE-POINTED 2026-08-03: the dc0 VIP overlay was reverted to IPv4-only under D-141 +# (the v6 GUA block reserved-until-capable in the apex), so the REAL deploy input is +# now v4-only. This used to assert "every app is dual-family"; that invariant is +# REPLACED, not deleted -- the real deploy input must read 0 dual-family. The +# dual-family full-count positive control moves to T21/T45 on the synthetic +# dual.yaml. When D-141 rule-3 promotes v6, re-point this back to dual-family. +run 0 '13 clustered VIP\(s\).*\(0 dual-family\)' \ + "T19 the real dc0 deploy input is v4-only under D-141 (0 dual-family)" "$TMP/good.yaml" # T20/T21 RE-POINTED 2026-07-31 (D-101 RULING NOTE (b), operator: "Set it false on the # seven, keep every v6 VIP leg"). Both previously asserted the COUPLING -- that the @@ -248,9 +274,11 @@ # T21 the ruled shape -- v6 legs present, option absent -- must PASS. This is the # positive control the absence rule needs: without it, 9b could be satisfied by -# rejecting everything. -run 0 '13 clustered VIP\(s\).*13 dual-family' \ - "T21 v6 legs WITHOUT the option PASSES (the ruled shape)" "$TMP/good.yaml" +# rejecting everything. RE-POINTED 2026-08-03 to the synthetic dual.yaml: under +# D-141 the real deploy input (good.yaml) is v4-only, so the dual-family shape is +# carried by the fixture promotion restores, not by good.yaml. +run 0 '13 clustered VIP\(s\).*\(13 dual-family\)' \ + "T21 v6 legs WITHOUT the option PASSES (the ruled shape)" "$TMP/dual.yaml" # T22 v6 provider leg in the NODE /64 instead of the dedicated GUA VIP /64 # NOTE: these no longer set prefer-ipv6. They did, because the OLD coupling required @@ -271,9 +299,11 @@ run 1 'neither a v4 triple .3. nor a dual-family sextet' "T24 2-address vip FAILS" "$TMP/t24.yaml" # T25 an unreadable apex REFUSES (rc=2) rather than passing -- "could not look" is -# never "nothing there". Only fires when a dual-family vip is actually present. +# never "nothing there". Only fires when a dual-family vip is actually present, so +# RE-POINTED 2026-08-03 to dual.yaml (good.yaml is v4-only under D-141 and needs no +# apex -- that path is T26). This keeps the refusal control on a live dual input. APEX_RECORD=/nonexistent/apex.json runargs 2 'cannot evaluate .* no readable apex record' \ - "T25 dual-family + unreadable apex REFUSES (rc=2)" "$TMP/good.yaml" + "T25 dual-family + unreadable apex REFUSES (rc=2)" "$TMP/dual.yaml" # T26 ...and a v4-only bundle does NOT need the apex at all (no spurious refusal) APEX_RECORD=/nonexistent/apex.json runargs 0 'PASS: Pattern A' \ @@ -441,8 +471,9 @@ # T45 the RULED shape passes: the six carry full dual-family vips and no option. This is # the positive control -- without it, 9a could be satisfied by rejecting everything. -run 0 '13 clustered VIP\(s\).*13 dual-family' \ - "T45 the ruled shape PASSES: six dual-family vips with no prefer-ipv6" "$TMP/good.yaml" +# RE-POINTED 2026-08-03 to dual.yaml (good.yaml is v4-only under D-141). +run 0 '13 clustered VIP\(s\).*\(13 dual-family\)' \ + "T45 the ruled shape PASSES: six dual-family vips with no prefer-ipv6" "$TMP/dual.yaml" # T46 9a AND 9b BOTH match this input, and the DIAGNOSIS must be 9a's. octavia with # prefer-ipv6 true AND a v4 triple satisfies the coupling rule's shape (prefer6