diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index f8b54cf..00b49e5 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -675,7 +675,32 @@ the underlay be finished to jumbo, which is precisely this bug's precondition. **OWED at the Octavia step of Stage 5: verify `o-hm0`'s MTU MATCHES `lb-mgmt-net`'s after deploy, not merely that the charm claims to set it.** Queued, not actioned. - Remaining: R8 (to re-present on corrected evidence), R9-R10 blocking, R12-R15 standing. + **R8 RULED 2026-07-27 -- exact utterance "I want to take a Octavia creates and owns its + own IPv6 network."** Recorded as a D-101 RULING NOTE; **CLOSES the octavia-family + sub-ruling the 2026-07-25 note left open**. Operator's 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." **THE RULING REQUIRES NO ARTIFACT CHANGE** -- + measured, `create-mgmt-network` is set NOWHERE in `bundle.yaml` or any overlay, so the + charm default `True` has always applied and VR0 deployed Octavia on exactly this shape. + Family confirmed to agree three ways: the charm's default lb-mgmt-subnet is IPv6 (LP + #1897418, verbatim) and is a **ULA** (the amphora address in LP #1911788 is + `fc00:fa21:...`, i.e. `fc00::/7`), which is precisely D-101's "IPv6-only ULA ... Octavia + lb-mgmt ... Internal, no external clients". **The apparent VR0 GUA contradiction was a + PAPER ALLOCATION** -- `lib-net.sh` gives VR0 six IPv4 planes and no lbaas plane, lists + `lbaas` in `STALE_SPACES`, and the as-built records that NIC as "idle (undefined; + ex-lbaas), raw NIC, no link". **CONSEQUENCE FOR D-111: 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 cannot come from the apex; record the absence as DELIBERATE so a later + reader does not "fix" it. **STANDING OBLIGATION carried forward: LP #2018998** (o-hm0 vs + lb-mgmt-net MTU, charm-octavia, High) is Fix Released in our lineage but **recurred + 2025-12-31 on octavia 14.0.0 / 2024.1 stable, our exact pin** -- the direct interaction + with R3's jumbo ruling. Owed at the Octavia step: verify `o-hm0`'s MTU MATCHES + `lb-mgmt-net`'s by measurement. NOT asserted: whether the charm attaches an external + gateway to the router it creates -- no config surface tells it to and ULA is not globally + routable, but isolation was not proven from docs; settle by inspecting the router at + deploy. + Remaining: R9-R10 blocking, R12-R15 standing. - Position inside Stage 3: deploy step A EXECUTED 2026-07-19 (6/0/6 exact; convergence zero -- `docs/audit/outer-plan-20260719-postA-converged.txt`). **Deploy step B diff --git a/docs/audit/octavia-ipv6-research-20260727.md b/docs/audit/octavia-ipv6-research-20260727.md index f7950f8..26b2879 100644 --- a/docs/audit/octavia-ipv6-research-20260727.md +++ b/docs/audit/octavia-ipv6-research-20260727.md @@ -191,6 +191,70 @@ network risk found by this research is the MTU coupling in 6b -- which is about MTU, not address family. +--- + +## 7. TWO OPERATOR-DIRECTED CHECKS (2026-07-27) + +The operator asked, before ruling: "The Octavia lb-mgmt-net is fully isolated and +invisible, right? Its using internal ULA that never leaves the DC?" Two checks were run +rather than answering from inference. + +### 7a. Is VR0's GUA LBaaS prefix a deployed fact contradicting D-101's ULA classification? +**NO -- it is a PAPER ALLOCATION and was never deployed.** Three independent lines: +- `scripts/lib-net.sh:22-29` -- VR0's deployed planes are SIX IPv4 `/22`s + (`10.12.4/8/12/16/32/36`). **There is no lbaas plane at all.** +- `scripts/lib-net.sh:34` -- `STALE_SPACES=( provider metal data fabric-data lbaas + provider-vip )`. **`lbaas` is explicitly listed as a RETIRED space.** +- `docs/maas-as-built-reference.md:75` -- `| 8_lbaas | enp11s0 | idle (undefined; + ex-lbaas) | raw NIC, no link | - |`. The NIC exists physically and was never brought + into service. +The apex marks `2602:f3e2:e02:80::/64` `status=active`, but so are ALL VR0 v6 subnets +(`:10` through `:50`), while D-101's own context line reads "v1 / DC0 is IPv4-only on +10.12.0.0/16". The whole VR0 v6 tree is a design record, not a deployment. +**Consequence: the GUA-vs-ULA contradiction dissolves. D-101's IPv6-only-ULA +classification for lb-mgmt stands unchallenged.** + +### 7b. What does the charm actually let you control? +**Almost nothing -- and that is the decisive fact.** `create-mgmt-network` (default +**True**) is the ONLY related option. Verbatim: "The `octavia` charm utilizes Neutron +Resource tags to locate networks, security groups and ports for use with the service. If +none are found the default behaviour is to create the resources required for management +of the load balancer instances. Set this to False if you want to be in control of +creation and management of these resources yourself." +There is **NO configuration option for CIDR, address family, router creation, or +north/south control**. So: +- Letting the charm create it means accepting a CHARM-CHOSEN prefix -- it cannot come + from the D-111 carve. +- Getting a specific prefix REQUIRES `create-mgmt-network: false`, and you then own the + network AND the security groups AND the ports AND the router, because resource TAGS are + how the charm finds them. + +### 7c. Isolation -- narrowed, NOT fully closed +The router resource is tagged "Router for IPv6 RA **or** north/south mgmt traffic" -- two +distinct purposes, one resource. On an IPv6 network a router is required for **Router +Advertisement** so amphorae get addresses at all; that implies nothing external. Whether +the charm additionally sets an EXTERNAL GATEWAY on it is what would make the network +non-isolated, and neither the config reference nor the deployment guide states it. +**Can be said:** there is no configuration surface by which the charm is TOLD to route it +externally, and ULA is not globally routable regardless. +**Cannot be asserted:** that the charm never attaches an external gateway on its own. +Settling it needs the charm source or a live deploy. **Cheaply answered at deploy time by +inspecting the router the charm creates** -- queued as a Stage-5 observation, not a blocker. + +## 8. WHAT THE ARTIFACTS ALREADY DO -- this ruling changes nothing + +Measured: **`create-mgmt-network` is set NOWHERE** in `bundle.yaml` or any overlay +(grep returns only prose mentions), so the charm default `True` has always applied. +Octavia's entire options block is `debug`, `openstack-origin`, `amp-image-tag`, `vip`. +VR0 deployed Octavia on exactly this shape (`scripts/phase-05-octavia-verify.sh`, +`scripts/phase-05-amphora-pipeline.sh` are VR0 phase scripts). + +**And the family closes the loop on D-101.** The amphora address quoted in LP #1911788 is +`fc00:fa21:3d5c:9cfd:f816:3eff:fef1:7fa1` -- `fc00::/7`, i.e. **ULA**. So the charm's +default IPv6 lb-mgmt-subnet is a ULA, which is exactly what D-101's family matrix +specifies for lb-mgmt ("IPv6-only ULA ... Octavia lb-mgmt ... Internal, no external +clients"). Charm default, D-101 classification and existing as-built all agree. + ## Sources - https://docs.openstack.org/octavia/latest/contributor/guides/dev-quick-start.html - https://bugs.launchpad.net/bugs/1911788 diff --git a/docs/design-decisions.md b/docs/design-decisions.md index 50d17a0..74ea6a1 100644 --- a/docs/design-decisions.md +++ b/docs/design-decisions.md @@ -2199,6 +2199,73 @@ them; see the corrected Effect above. Nothing further is owed from the operator on the address values. +### RULING NOTE 2026-07-27 -- D-101: Octavia lb-mgmt CONFIRMED IPv6-ULA, charm-owned; the open sub-ruling is CLOSED + +**Status:** RULED 2026-07-27 (operator, GA-R5). CLOSES the sub-ruling the 2026-07-25 note +left open ("STILL OPEN under this ruling: octavia's family"). Amends nothing in D-101's +matrix -- it CONFIRMS it. + +Question as presented: whether Octavia's `lb-mgmt-net` should be IPv6 (per D-101's +IPv6-only-ULA classification and the charm's own default), v4-only as a recorded D-101 +exception (the shape `overlays/dc-dc-ipv6-family-matrix.yaml` drafted), or dual-stack; and +separately whether the prefix should come from the D-111 carve via +`create-mgmt-network: false` or be left to the charm. Operator selection, exact utterance: +**"I want to take a Octavia creates and owns its own IPv6 network."** Supporting reasoning +given by the operator, 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 RULING REQUIRES NO ARTIFACT CHANGE.** Measured: `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. The ruling ratifies the existing topology rather +than changing it -- the operator's point that it is already proven in the v1 DC test +deployments is correct on the artifacts. + +**THE EVIDENCE THAT SUPPORTED THE v4-ONLY DRAFT DOES NOT HOLD.** Full research capture: +`docs/audit/octavia-ipv6-research-20260727.md`. Both citations in +`overlays/dc-dc-ipv6-family-matrix.yaml` fail on inspection: **LP #1913409** is Fix Released +(2021) against **kolla-ansible**, a different installer with no bearing on a charm deploy; +**LP #1911788** is Incomplete and a DUPLICATE of **LP #1896630**, and is NOT an IPv6 defect +-- its diagnosed cause is an OVN port-binding shortname-vs-FQDN mismatch for LXD containers +on MAAS, fixed by `ovs-record-hostname.service` **in OVS 2.15**. This deployment's own dc0 +mirror was queried: our jammy nodes install **openvswitch-switch 2.17.0 / 2.17.9**, so that +mechanism is fixed here. Against them, upstream Octavia documents that "IPv6 subnets can be +used for the LB Network", and **LP #1897418 records the charm's default verbatim: "By +default, Octavia charm uses ipv6 for its lb-mgmt-subnet."** + +**FAMILY CONFIRMATION -- the charm's default IS a ULA.** The amphora address quoted in LP +#1911788 is `fc00:fa21:3d5c:9cfd:...`, i.e. `fc00::/7`. So charm default, D-101's +"IPv6-only ULA ... Octavia lb-mgmt ... Internal, no external clients" classification, and +the existing as-built all agree. + +**AND THE VR0 GUA CONTRADICTION WAS A PAPER ALLOCATION.** The apex carries +`2602:f3e2:e02:80::/60,/64` "VR0 DC0 Omega Cloud LBaaS Management Prefix/Subnet" in GUA +space, which appeared to contradict the ULA classification. It was never deployed: +`lib-net.sh:22-29` gives VR0 six IPv4 planes and no lbaas plane; `lib-net.sh:34` lists +`lbaas` in `STALE_SPACES`; `maas-as-built-reference.md:75` records the lbaas NIC as "idle +(undefined; ex-lbaas), raw NIC, no link". D-101's own context line says VR0 is IPv4-only. + +**CONSEQUENCE FOR THE D-111 CARVE:** because the charm owns the network and exposes NO CIDR +option, the absence of an lb-mgmt `:x80` prefix in the VR1 ULA carve is now CORRECT rather +than a gap -- the prefix is charm-generated and cannot come from the apex. That absence +should be recorded as DELIBERATE so a later reader does not "fix" it. + +**STANDING OBLIGATION, carried by the operator's own reasoning:** LP #2018998 ("MTU mismatch +between o-hm0 and lb-mgmt-net", 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 >1500B and causes +SPURIOUS failovers. This is the direct interaction with the R3 jumbo-underlay ruling. Owed +at the Octavia step of Stage 5: **verify `o-hm0`'s MTU MATCHES `lb-mgmt-net`'s, measured, +not merely that the charm claims to set it.** Workaround if needed: +`ovs-vsctl set interface o-hm0 mtu_request=`. + +**ONE THING NOT ASSERTED:** whether the charm attaches an EXTERNAL GATEWAY to the Neutron +router it creates (tagged "Router for IPv6 RA or north/south mgmt traffic"). There is no +config surface telling it to, and ULA is not globally routable, but isolation was not +proven from the docs. Cheaply settled at deploy time by inspecting the router the charm +creates -- queued as a Stage-5 observation, not a blocker. + ### RULING NOTE 2026-07-27 -- D-101 MTU sub-policy RESOLVED to the jumbo branch **Status:** RULED 2026-07-27 (operator, GA-R5). D-102 (the original MTU sub-policy) is