|
R8 RULED: Octavia creates and owns its own IPv6 network (D-101 note; sub-ruling closed)
GA-R5: question and exact utterance quoted, dated, pushed before dependent work. Operator utterance: "I want to take a Octavia creates and owns its own IPv6 network." Supporting reasoning recorded because it is load-bearing: "We have to research to troubleshoot if we run into MTU bug issues down the road. We have already deployed using this topology in the v1 DC test deployments that got us to this point." This CLOSES the octavia-family sub-ruling that the 2026-07-25 D-101 note left explicitly open. THE RULING REQUIRES NO ARTIFACT CHANGE, and the operator's reasoning checks out on the artifacts: create-mgmt-network is set NOWHERE in bundle.yaml or any overlay, so the charm default True has always applied, and Octavia's whole options block is debug, openstack-origin, amp-image-tag, vip. VR0 deployed Octavia on precisely this shape. This ratifies the existing topology rather than changing it. FAMILY AGREES THREE WAYS. The charm's default lb-mgmt-subnet is IPv6 (LP #1897418, verbatim: "By default, Octavia charm uses ipv6 for its lb-mgmt-subnet") and it is a ULA -- the amphora address quoted in LP #1911788 is fc00:fa21:3d5c:9cfd:..., i.e. fc00::/7. That is exactly D-101's "IPv6-only ULA ... Octavia lb-mgmt ... Internal, no external clients". THE APPARENT VR0 GUA CONTRADICTION WAS A PAPER ALLOCATION, checked on operator instruction: lib-net.sh gives VR0 six IPv4 planes and no lbaas plane; lbaas is listed in STALE_SPACES; maas-as-built-reference records that NIC as "idle (undefined; ex-lbaas), raw NIC, no link"; and D-101's own context says VR0 is IPv4-only. The whole VR0 v6 tree in the apex is a design record. CONSEQUENCE FOR D-111, worth recording so it is not later "fixed": the absence of an lb-mgmt :x80 prefix in the VR1 ULA carve is CORRECT, not a gap. The charm exposes no CIDR option, so the prefix is charm-generated and cannot come from the apex. STANDING OBLIGATION carried by the operator's own reasoning: LP #2018998 (o-hm0 vs lb-mgmt-net MTU, charm-octavia, High) is Fix Released across our lineage but recurred 2025-12-31 against octavia 14.0.0 / 2024.1 stable -- our exact pin. A jumbo lb-mgmt-net beside a 1500 o-hm0 silently drops health messages over 1500 bytes and causes spurious failovers, which is the direct interaction with R3's jumbo-underlay ruling. Owed at the Octavia step: verify o-hm0's MTU MATCHES lb-mgmt-net's by measurement, not by trusting the charm. NOT ASSERTED: whether the charm attaches an external gateway to the Neutron router it creates. No config surface tells it to and ULA is not globally routable, but isolation was not proven from the documentation. Settle by inspecting the router at deploy time; queued as an observation, not a blocker. Revert: git revert this commit; the ruling note and research sections are additive. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf |
|---|
|
|
| docs/CURRENT-STATE.md |
|---|
| docs/audit/octavia-ipv6-research-20260727.md |
|---|
| docs/design-decisions.md |
|---|