|
Ruling 3 commit 2: dual-stack ADD -- R2 and R11 are now BUILT, L3-9 resolved
Both per-DC VIP overlays re-rendered dual-family: every app carries prefer-ipv6: true and a six-address vip, and vault .61 + designate .62 are built. Measured both DCs: 13 clustered VIPs (13 dual-family) + 12 hacluster principals all carrying a VIP -> PASS. With dc-ha-scaleup stacked: 13 principals, PASS -- R6's ruled ordering (VIPs before the HA overlay) is now satisfied and executable. Two ruled-but-never-built decisions became artifacts in one pass. L3-9 RESOLVED. dc-dc-ipv6-family-matrix.yaml is narrowed to ceph-mon only; its ten duplicate vip + prefer-ipv6 pairs (every value an unrendered token) are gone, removed TOGETHER -- removing the vips alone would have recreated the defect deliberately. Both merge orders now PASS, i.e. order-independent, which is the actual fix. ceph-mon's ULA-only networks survive because they exist in no other file. The two Launchpad citations arguing octavia lb-mgmt IPv6 was an open risk are removed: both were read in full and both failed, and R8 closed that question on 2026-07-27. Also corrected at source: CURRENT-STATE described L3-9 as "the dangerous merge order is the one that PASSES". Measured -- that stopped being true when invariant 9 shipped on 2026-07-28. The merge semantics it describes remain accurate; only the green-over-loss conclusion is retired. Gate repairs the agents caught BEFORE the edit: - phase-01's deploy guard would have ABORTED THE DEPLOY AGAIN -- its HI regex (5[0-9]|60) excludes .61/.62, so it would have read 13/11/0 against a required 11/11/0. Widened, counts moved to 13, verified 13/13/0 -> DEPLOY. Second near-miss on this one guard across two commits. - pre-flight-checks CHECK 1 hardcoded if(n!=3) and would have failed all 13. Now takes a triple OR a sextet and asserts a sextet's last three legs are really v6. Proven able to fail on both new paths. Harnesses re-pointed, never deleted. T16/T17 asserted R11's gaps were OPEN; inverted to the surviving invariant and PAIRED with new T16b/T17b that remove a VIP and demand the check still fires. T20/T21 had become no-ops that would have gone GREEN testing nothing -- inverted. A v4-only twin fixture keeps the pre-dual-stack cases testing their own invariants. The renderer harness now proves reproduction on both shapes, including new T3b against the live dual-family overlay. provider-bundle-check 33/33; render-dc-overlays 18/18; render-baseline 10/10; preflight 16/16; gauntlet ALL GREEN (85) on vcloud; repo-lint 0 fail / 611. PREFLIGHT: BOTH STANDING REDS CLEARED, 3 fatal -> 2 fatal. The remaining two are the deliberately-absent octavia-pki overlay and MAAS unreachable from vcloud, which R10 measured clears on voffice1. FLAGGED, not hidden: octavia's dual-family API VIP is an inference from R2 applied evenly, not a quoted ruling. Worth one operator confirmation. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf |
|---|
|
|
| docs/CURRENT-STATE.md |
|---|
| docs/changelog-20260728-vip-arity-gate.md |
|---|
| overlays/dc-dc-ipv6-family-matrix.yaml |
|---|
| overlays/vr1-dc0-vips.yaml |
|---|
| overlays/vr1-dc1-vips.yaml |
|---|
| render/values/vr1-dc0-vips.yaml |
|---|
| render/values/vr1-dc1-vips.yaml |
|---|
| runbooks/phase-01-bundle-deploy.md |
|---|
| scripts/pre-flight-checks.sh |
|---|
| tests/provider-bundle-check/run-tests.sh |
|---|
| tests/render-dc-overlays/run-tests.sh |
|---|