|
D-109 ruling note: the Octavia controller cert gains IPv6 IP SANs
Operator ruling (GA-R5), exact utterance: "Yes, add the v6 IP sans." Recorded as a D-109 RULING NOTE (2026-07-29); OPS under GA-R3 -- a generator change extending an already-ruled principle to a surface D-109 governs -- so no new D-number and next-free stays 138. The generator now emits IP.1 = this DC's provider v4 leg and IP.2 = its provider v6 leg, both derived from the same per-DC overlay under R7's $DC selector. Verified: dc0 -> 10.12.4.57 + 2602:f3e2:f02:11::57; dc1 -> 10.12.64.57 + 2602:f3e2:f03:11::57; and a v4-only control emits NO v6 SAN, so the generator stays correct on a tree where the dual-stack ADD has not landed. Admin and internal legs stay EXCLUDED exactly as before -- DOCFIX-067's design has always been provider-leg-only. Two repo guards fired and both were right: repo-lint L5 rejected a heading that LED with the D-number (it reads as a second definition -- the third time this trap has bitten on this branch), and L10 rejected the change for touching a design-decisions Status line without CURRENT-STATE in the same commit. Observation logged, not acted on: amphorae reach the controller on o-hm0's charm-generated fc00::/64 ULA, not on any VIP leg, so neither SAN matches that path. Measured upstream, the controller verifies the amphora by UUID; the reverse direction was not established from source. Settle by inspection at the Octavia step rather than assuming. Gauntlet ALL GREEN (85) on vcloud; repo-lint 0 fail / 611 files. 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 |
|---|
| docs/design-decisions.md |
|---|
| runbooks/phase-01-bundle-deploy.md |
|---|