OpenStack/openstack-caracal-dc-dc

Fork: 0

OpenStack / openstack-caracal-dc-dc

History for openstack-caracal-dc-dc / docs / audit / octavia-ipv6-research-20260727.md

2026-07-27	a7fb679 Browse files » 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 JANeumatrix committed 3 hours ago
f782598 Browse files » R8 research: both in-repo citations fail; charm default is IPv6; new MTU risk found ... Operator declined to rule on the overlay's own citations -- "I would like documentation and vendor specific information rather than conjecture. Research is cheap, guesswork is expensive" -- then directed a full read of two bugs weighed against current versions. That was the right call and it inverted the answer. 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. No bearing on a Juju/charm deployment. - LP #1911788 is Incomplete and a DUPLICATE of LP #1896630, and is NOT an IPv6 defect. Its diagnosed cause is an OVN port-binding hostname mismatch -- binding_host_id carrying the shortname instead of the FQDN for LXD containers on MAAS, giving binding_failed instead of ovs. The IPv6 address in the timeout was incidental; the port never bound, so nothing would have worked over any family. VERSION WEIGHING, verified rather than asserted. #1896630's primary fix is ovs-record-hostname.service, which the bug places in OVS 2.15 (Focal shipped 2.13). Rather than assume, I queried THIS DEPLOYMENT'S OWN dc0 mirror for what a jammy node would actually install: openvswitch-switch 2.17.0-0ubuntu1 (jammy) and 2.17.9-0ubuntu0.22.04.2 (jammy-updates). 2.17.9 >> 2.15, so the fix is present on every node this deployment will build. The bug's era was Juju 2.7.8, charms 20.08 Ussuri, Focal/OVS 2.13; we are Juju 3.6.27, charms 2024.1, jammy/OVS 2.17.9. The charm-layer-ovn task -- the one closest to this repo's OVN usage -- is closed Invalid. AND THE DEFAULT RUNS THE OTHER WAY: LP #1897418 records, verbatim, "By default, Octavia charm uses ipv6 for its lb-mgmt-subnet", with a reporter noting success "using the charm default (ipv6) network but using ipv4 everywhere else". Upstream Octavia documents that "IPv6 subnets can be used for the LB Network". So D-101's IPv6-only placement of lb-mgmt is ALIGNED with the charm default, and a v4-only lb-mgmt-net would be the DEPARTURE requiring justification -- the opposite of how R8 was first framed. NEW LIVE RISK FOUND, COUPLED TO THE R3 RULING: LP #2018998 "MTU mismatch between o-hm0 and lb-mgmt-net" (charm-octavia, High, Edward Hope-Morley). A jumbo lb-mgmt-net beside a 1500 o-hm0 silently drops health messages over 1500 bytes and triggers SPURIOUS load-balancer failovers -- evidenced in the bug as "UDP, length 1534 > 1500 and o-hm0 never receives them" and "o-hm0: dropped over-mtu packet: 1744 > 1500". Fix Released across our lineage, BUT a recurrence was reported 2025-12-31 against octavia 14.0.0 / 2024.1 stable, the exact channel bundle.yaml pins. R3 ruled 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. GENERALISABLE LESSON, recorded in the capture: a bug NUMBER in a comment is an existence claim; what the bug SAYS is the content, and only content is evidence. Same class as the two ruled-but-never-built decisions this audit already found -- a plausible in-repo statement that nothing verifies. R8 is NOT ruled by this commit. It will be re-presented on corrected evidence. Revert: git revert this commit; the capture is new and CURRENT-STATE additive. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf JANeumatrix committed 3 hours ago

2026-07-27

a7fb679
Browse files »

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

JANeumatrix committed 3 hours ago

f782598
Browse files »

R8 research: both in-repo citations fail; charm default is IPv6; new MTU risk found ...

Operator declined to rule on the overlay's own citations -- "I would like
documentation and vendor specific information rather than conjecture. Research is
cheap, guesswork is expensive" -- then directed a full read of two bugs weighed
against current versions. That was the right call and it inverted the answer.

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. No bearing on a Juju/charm deployment.
- LP #1911788 is Incomplete and a DUPLICATE of LP #1896630, and is NOT an IPv6
defect. Its diagnosed cause is an OVN port-binding hostname mismatch --
binding_host_id carrying the shortname instead of the FQDN for LXD containers
on MAAS, giving binding_failed instead of ovs. The IPv6 address in the timeout
was incidental; the port never bound, so nothing would have worked over any
family.

VERSION WEIGHING, verified rather than asserted. #1896630's primary fix is
ovs-record-hostname.service, which the bug places in OVS 2.15 (Focal shipped
2.13). Rather than assume, I queried THIS DEPLOYMENT'S OWN dc0 mirror for what a
jammy node would actually install: openvswitch-switch 2.17.0-0ubuntu1 (jammy) and
2.17.9-0ubuntu0.22.04.2 (jammy-updates). 2.17.9 >> 2.15, so the fix is present on
every node this deployment will build. The bug's era was Juju 2.7.8, charms 20.08
Ussuri, Focal/OVS 2.13; we are Juju 3.6.27, charms 2024.1, jammy/OVS 2.17.9. The
charm-layer-ovn task -- the one closest to this repo's OVN usage -- is closed
Invalid.

AND THE DEFAULT RUNS THE OTHER WAY: LP #1897418 records, verbatim, "By default,
Octavia charm uses ipv6 for its lb-mgmt-subnet", with a reporter noting success
"using the charm default (ipv6) network but using ipv4 everywhere else". Upstream
Octavia documents that "IPv6 subnets can be used for the LB Network". So D-101's
IPv6-only placement of lb-mgmt is ALIGNED with the charm default, and a v4-only
lb-mgmt-net would be the DEPARTURE requiring justification -- the opposite of how
R8 was first framed.

NEW LIVE RISK FOUND, COUPLED TO THE R3 RULING: LP #2018998 "MTU mismatch between
o-hm0 and lb-mgmt-net" (charm-octavia, High, Edward Hope-Morley). A jumbo
lb-mgmt-net beside a 1500 o-hm0 silently drops health messages over 1500 bytes
and triggers SPURIOUS load-balancer failovers -- evidenced in the bug as "UDP,
length 1534 > 1500 and o-hm0 never receives them" and "o-hm0: dropped over-mtu
packet: 1744 > 1500". Fix Released across our lineage, BUT a recurrence was
reported 2025-12-31 against octavia 14.0.0 / 2024.1 stable, the exact channel
bundle.yaml pins. R3 ruled 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.

GENERALISABLE LESSON, recorded in the capture: a bug NUMBER in a comment is an
existence claim; what the bug SAYS is the content, and only content is evidence.
Same class as the two ruled-but-never-built decisions this audit already found --
a plausible in-repo statement that nothing verifies.

R8 is NOT ruled by this commit. It will be re-presented on corrected evidence.

Revert: git revert this commit; the capture is new and CURRENT-STATE additive.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf

JANeumatrix committed 3 hours ago