|
RULED 2026-07-31 (GA-R5): prefer-ipv6 set on NO application until IPv6 is operational
Operator utterance, verbatim: 'Set it false on the seven, keep every v6 VIP leg (Recommended)'. Standing context from the same exchange: 'We have DC1 to stand up with the IPv6 configuration changes. Lets continue with the IPv4/6 stand up on DC0. We will fold in all lessons learned from the DC0 stand up into the DC1 stand up.' Recorded as a D-101 RULING NOTE 2026-07-31 (b). OPS under GA-R3, no D-number; D-101's matrix is UNAMENDED and every dual-family VIP is retained. It supersedes the emission half of note (a) and now covers all thirteen apps. Measured cause: get_relation_ip() returns early with get_ipv6_addr()[0] when the option is true, and the LXD containers hold ONLY a link-local v6 while the HOSTS are fully dual-stacked. Why this is not abandoning v6: the option is a unit ADDRESS-FAMILY switch, not a listener switch. HAProxy's :::port bind is gated on the kernel sysctl and pacemaker selects IPv6addr by family detection. Neither consults it. HONEST RESIDUAL, recorded not glossed: pacemaker will place a v6 VIP on a container whose eth0 has no global v6, and whether that leg is ROUTABLE is UNVERIFIED. Not a regression -- true today -- but it is what the v6 completion work must close. GATE CONSEQUENCE: invariant 9b coupled the option to the v6 legs for declaring charms and would now FAIL. It is RE-POINTED to the new invariant and re-proven, never deleted; when IPv6 becomes operational it returns to its coupling form and this note records why it left. Committed and pushed BEFORE the dependent work. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf |
|---|
|
|
| docs/CURRENT-STATE.md |
|---|
| docs/design-decisions.md |
|---|