diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index bb62fca..f6c70f2 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -1062,6 +1062,20 @@ owed before the redeploy, and each could cost an attempt the same way. An unreadable or unrecognised schema REFUSES rather than passing. **A REPO GATE FOR THIS IS OWED, NOT BUILT** (hard rule 1 + the standing directive); the method is reproduced verbatim in the capture. + **>>> RULED 2026-07-31 (GA-R5) -- OPTION (b) ADOPTED: THE SIX DROP `prefer-ipv6` AND KEEP + THEIR v6 VIP LEGS. <<<** Recorded as a D-101 RULING NOTE dated 2026-07-31 + (`docs/design-decisions.md`, after the R8 note) -- OPS under GA-R3, no D-number, and D-101's + matrix is UNAMENDED. **Operator utterance, verbatim: "I want it to use IPv6, if there is + spam mechanisms being applied then that is bad. Even if it doesn't cause an issue now, it + might in the future. A clean IPv6 network is better than one with unusable and possibly + future breaking configurations."** That stated a PRINCIPLE rather than selecting an option, + so a confirming exchange was taken rather than adopting an inferred ruling (GA-R5): + **"Yes -- keep the v6 legs, remove only the option"**. CONSEQUENCE: `barbican`, `designate`, + `magnum`, `octavia`, `placement` and `vault` keep all three v6 VIP legs each; `prefer-ipv6` + stops being emitted for them; both DCs, symmetric. The work is (i) the renderer becomes + charm-schema-aware, (ii) `tests/render-drift` re-pointed, (iii) `provider-bundle-check` + invariant 9 REPLACED and proven able to fail both ways -- never deleted to go green. + **The SEVEN are NOT covered by this ruling** and were deliberately not bundled into it. **RUNBOOK DEFECT FOUND IN PASSING, LOGGED NOT FIXED (DOCFIX material):** `runbooks/dc-dc-phase4-juju-bundle-per-dc.md:553-557` gives the dc0 deploy WITHOUT `overlays/vr1-dc0-machines.yaml`, while the dc1 block three lines below includes its diff --git a/docs/design-decisions.md b/docs/design-decisions.md index 311234d..f70e144 100644 --- a/docs/design-decisions.md +++ b/docs/design-decisions.md @@ -2434,6 +2434,69 @@ BEFORE the L3-9 overlay-collision reconciliation, since that reconciliation needs the per-app dual-family values these produce. +### RULING NOTE 2026-07-31 -- D-101 / R2: `prefer-ipv6` is DROPPED from the six charms that do not declare it; the v6 VIP legs STAY + +**Status:** RULED 2026-07-31 (operator, GA-R5). Like its predecessors this NOTE records a +ruling and AMENDS NOTHING in D-101's matrix -- the dual-stack posture is UNCHANGED and every +v6 VIP leg is retained. **OPS under GA-R3 (a renderer + gate change; doubt resolves DOWN, so +no D-number is assigned).** It corrects the MECHANISM belief inside R2's implementation, not +the address-family policy R2 confirmed. + +Why the question arose: bundle deploy attempt 1 failed 2026-07-31 with `ERROR cannot deploy +bundle: cannot deploy application "barbican": unknown option "prefer-ipv6"`. R2's +implementation applies `prefer-ipv6: true` to all thirteen VIP apps, but only SEVEN charms +declare the option. + +**THE MEASUREMENT, from the charm ARTIFACTS at their pinned revisions** (capture +`docs/audit/stage5-prefer-ipv6-charm-research-20260731.txt`; barbican 265, designate 418, +magnum 96, octavia 571, placement 154, vault 724, with keystone 857 + cinder 820 as +declaring-charm controls). **`prefer-ipv6` is not what makes HAProxy bind `:::port`, and +never was, for any of the thirteen.** In BOTH template families the v6 frontend bind is +gated on `ipv6_enabled = not is_ipv6_disabled()` -- a read of the kernel +`net.ipv6.conf.all.disable_ipv6` sysctl, MEASURED `0` on a live MAAS-deployed jammy node in +dc0. Pacemaker selects `ocf:heartbeat:IPv6addr` by per-address family detection, also +independent of the option. Vault ships no haproxy template at all; its listener is the +hardcoded literal `[::]:8200`. What `prefer-ipv6` really is: a UNIT ADDRESS-FAMILY switch -- +`get_relation_ip()` returns early with the unit's IPv6 address for every relation, ignoring +the network-space binding. + +Question as presented: for those six charms at their pinned channels, does the generated +HAProxy config bind `:::port` without the option -- and given it does, (b) drop the option +only and keep the v6 legs, or (c) drop both and make the six v4-only? + +Operator utterance, verbatim (2026-07-31): **"I want it to use IPv6, if there is spam +mechanisms being applied then that is bad. Even if it doesn't cause an issue now, it might +in the future. A clean IPv6 network is better than one with unusable and possibly future +breaking configurations."** + +Confirming exchange, verbatim, taken because the first utterance stated a principle rather +than selecting an option and GA-R5 forbids adopting an inferred ruling: **"Yes -- keep the +v6 legs, remove only the option"**. + +**Effect.** The six -- `barbican`, `designate`, `magnum`, `octavia`, `placement`, `vault` -- +KEEP all three v6 VIP legs each, and `prefer-ipv6` stops being emitted for them. Both DCs, +symmetric. + +**What this costs, measured BEFORE the ruling was put so it was taken on the real price: +it is NOT a values-file edit.** `prefer-ipv6: true` is injected UNCONDITIONALLY by +`scripts/render-dc-overlays.py:243-246` for every app whenever `fam == "dual"`, and +`family: dual` is a single TOP-LEVEL key in `render/values/vr1-dc{0,1}-vips.yaml:3`, not +per-app data. Implementing this ruling means (i) teaching the renderer which charms DECLARE +the option, (ii) re-pointing `tests/render-drift`, and (iii) REPLACING +`provider-bundle-check` invariant 9, whose mechanism claim ("prefer-ipv6 makes HAProxy bind +:::port in ADDITION to *:port, so the two must travel together") is refuted above. The +invariant's ARITY half was a real measured defect (L3-9) and is retained; only the coupling +half changes, and the replacement is proven able to fail in both directions. **Never deleted +to go green** -- the standing rule that a checker which cannot fail is not a gate. + +**NOT RULED HERE, and deliberately not bundled (GA-R5: one decision per exchange): what the +SEVEN declaring charms should do.** R2 set the option true on all thirteen in order to +obtain v6 VIP binding, which is not what it does. On the seven, true means every relation +carries an IPv6 address chosen from the unit's primary interface, ignoring the network-space +binding -- in a bundle that binds relations across six named spaces. Never observed live. +That is its own GA-R5 exchange, and the operator's stated principle above ("unusable and +possibly future breaking configurations") bears on it but has not been applied to it. + --- ## D-102: IPv6 tenant addressing and MTU sub-policy (VR1)