diff --git a/docs/changelog-20260709-ipv6-family-matrix-overlay.md b/docs/changelog-20260709-ipv6-family-matrix-overlay.md new file mode 100644 index 0000000..f4b5db4 --- /dev/null +++ b/docs/changelog-20260709-ipv6-family-matrix-overlay.md @@ -0,0 +1,71 @@ +# Changelog 2026-07-10 -- D-101 IPv6 family-matrix overlay drafted (DOCFIX-164) + +No live infrastructure touched -- new overlay + research memo, and +existing-doc updates. Closes the "overlay doesn't exist" half of tooling +gap register item #13; researched and authored directly (not delegated), +given the accuracy stakes of getting charm config option names right. + +## Item + +### 1. DOCFIX-164 -- `overlays/dc-dc-ipv6-family-matrix.yaml` + research memo +FILES: `overlays/dc-dc-ipv6-family-matrix.yaml` (new), `docs/dc-dc-ipv6- +charm-research.md` (new, full sourcing), `runbooks/dc-dc-phase4-juju- +bundle-per-dc.md` (Step 6 updated from "NOT YET WRITTEN" to "DRAFTED"), +`docs/dc-dc-deployment-workflow.md` (gap #13 updated). + +WHAT: researched real charm config/source directly (WebFetch/WebSearch +against `openstack/charm-*` GitHub mirrors and Launchpad, not memory) to +build a sourced IPv6/dual-stack overlay for the nine dual-stack API +charms plus `ceph-mon`'s ULA-only switch, rather than guessing plausible +option names. + +**Key findings, each independently confirmed by reading real source:** +- `prefer-ipv6` is a real, shared charms.openstack-family config option + (confirmed in `charm-keystone/config.yaml`). +- It is genuinely ADDITIVE dual-stack, not either/or -- confirmed by + reading `charm-nova-cloud-controller`'s actual "Dual Stack VIPs" commit: + HAProxy binds both `*:port` (v4) and `:::port` (v6) simultaneously when + the flag is set. +- `ceph-mon` has its OWN separate `prefer-ipv6` + `ceph-public-network`/ + `ceph-cluster-network`, which per the charm's own docs IS a straight + either/or switch -- the correct shape for D-101's ULA-only storage/ + replication planes. +- OVN (`ovn-central`/`ovn-chassis`, via `charm-layer-ovn`) has NO IPv6/ + encapsulation config option at all (confirmed: fetched and read the + full 25-option `config.yaml`) -- geneve family follows the bound + interface automatically once the plane is ULA-only; no overlay entry + needed or written for it. +- `charm-vault`'s cert-issuance code (`vault_pki.py`'s `sort_sans()`) has + no IPv4/IPv6 distinction -- D-109's IPv6-SAN requirement is code- + confirmed, not merely assumed. + +**A real, open risk found and deliberately NOT worked around:** Octavia's +`lb-mgmt-net` (the amphora management network D-101 wants ULA-only) has +two real, still-referenced Launchpad bug reports describing IPv6 failures +(#1911788, #1913409). #1911788's root cause is an OVN/LXD/MAAS hostname- +resolution mismatch -- the SAME CLASS of problem this repo's own D-008 +bootstrap order already hardens against, so not necessarily fatal, but +genuinely unresolved. The overlay deliberately excludes an Octavia entry +rather than silently forcing the risk through; both paths forward +(accept and test, or keep Octavia's lb-mgmt-net as a deliberate v4-only +exception) are presented for an explicit operator decision. + +**Also flagged, not silently assumed:** 8 of the 9 dual-stack charms' +`prefer-ipv6` presence is inferred by shared-framework pattern (very high +confidence, but not each individually fetched) -- confirm via `juju +config ` once any is actually deployed. + +VERIFIED: `bash scripts/repo-lint.sh` 0 fail, 1 documented legacy warn. +UNVALIDATED against any live model -- no Juju session this evening. + +REVERT: `rm overlays/dc-dc-ipv6-family-matrix.yaml docs/dc-dc-ipv6-charm- +research.md && git checkout HEAD~ -- runbooks/dc-dc-phase4-juju-bundle- +per-dc.md docs/dc-dc-deployment-workflow.md` (safe -- nothing applied +live). + +## Next actionable step + +Before Stage 5's runbook can honestly close its "Ceph-over-v6 and geneve- +over-v6 verified" gate: (a) confirm the 8 inferred-by-pattern charms' +`prefer-ipv6` option live, once any is deployed; (b) get an explicit +operator decision on the Octavia lb-mgmt-net IPv6 risk. diff --git a/docs/dc-dc-ipv6-charm-research.md b/docs/dc-dc-ipv6-charm-research.md new file mode 100644 index 0000000..9c48ba2 --- /dev/null +++ b/docs/dc-dc-ipv6-charm-research.md @@ -0,0 +1,142 @@ +# D-101 IPv6 family-matrix charm research (2026-07-09/10) + +Basis for `overlays/dc-dc-ipv6-family-matrix.yaml` (tooling gap register item +#13). Researched directly against real charm source/config via WebFetch/ +WebSearch -- not inferred from training-data memory of charm behavior, which +this repo's own discipline treats as a real risk class (the OpenTofu module +work earlier this session found a real syntax bug from exactly that mistake). + +## Method + +Fetched actual `config.yaml` files and, where a config option's semantics +were ambiguous from prose alone, actual charm source/commits, from the +`openstack/charm-*` and `openstack-charmers/charm-layer-ovn` repositories +(GitHub mirrors of the OpenDev-hosted canonical source) and +`bugs.launchpad.net`. Every claim below is labeled CONFIRMED (read the +actual file/commit) or INFERRED-BY-PATTERN (not independently checked, +reasoned from a shared framework) -- do not treat the two as equal +confidence. + +## Findings + +### 1. `prefer-ipv6` is a real, shared charms.openstack-family config option + +**CONFIRMED** directly in `charm-keystone/config.yaml`: a boolean, default +`False`, enabling IPv6 support. + +**CONFIRMED** via `charm-nova-cloud-controller`'s actual "Dual Stack VIPs" +commit (`1fa5f7a673006bc6faaf9d377e791448a5ed661b`): setting `prefer-ipv6: +true` causes the charm's HAProxy config template to add `bind +:::{{ports[0]}}` ALONGSIDE the existing `bind *:{{ports[0]}}` -- i.e. this +is a genuinely ADDITIVE dual-stack switch (HAProxy listens on both address +families simultaneously), not an either/or toggle. The commit message +states this explicitly: "HAProxy always listens on both IPv4 and IPv6 +allowing connectivity on either protocol." + +**INFERRED-BY-PATTERN, NOT independently confirmed per-charm:** glance, +neutron-api, placement, cinder, barbican, magnum, openstack-dashboard, +ceph-radosgw all build on the same charms.openstack base classes as +keystone/nova-cloud-controller, so the same `prefer-ipv6` option and +additive-dual-stack HAProxy behavior is EXPECTED -- but each charm's real +`config.yaml` was not individually fetched this session. Confirm via `juju +config ` once any of these charms is actually deployed, before +trusting the overlay is complete for all eleven. + +### 2. The existing `vip:` option takes additional v6 addresses, appended + +**CONFIRMED**: `charm-keystone/config.yaml`'s `vip` option description: +"Virtual IP(s) to use to front API services in HA configuration. If +multiple networks are being used, a VIP should be provided for each +network, separated by spaces." This repo's `bundle.yaml` already uses this +exact mechanism today (D-020's triple-VIP pattern -- e.g. `keystone`'s `vip: +"10.12.4.50 10.12.8.50 10.12.12.50"`, one address per Juju-space binding). +Adding v6/GUA addresses to the SAME space-separated list, once +`prefer-ipv6: true` makes HAProxy listen on both families, is the +mechanism -- confirmed consistent with finding #1's dual-stack commit, +though the EXACT mapping of "which list position pairs with which network" +inside the charm's own context-building code was not traced line-by-line +this session. Treat the overlay's VIP ordering (existing v4 entries first, +then the new v6/GUA entries appended) as the reasonable, but not +byte-for-byte charm-source-confirmed, convention. + +### 3. `ceph-mon` has a real, separate `prefer-ipv6` + network-CIDR mechanism + +**CONFIRMED** directly in `charm-ceph-mon/config.yaml`: +- `prefer-ipv6` (bool, default False) -- per the charm's OWN description, + "If set to False (default) IPv4 is expected," reading as a straight + EITHER/OR switch for THIS charm specifically (unlike the additive + HAProxy behavior in finding #1) -- which is actually the correct shape + for D-101's ULA-ONLY storage/replication planes (no v4 needed at all, + so a clean switch to v6-only is exactly right, not a limitation). +- `ceph-public-network` / `ceph-cluster-network` (string, space-delimited + CIDR list) -- these map directly to D-101's own cited mechanism name, + `ms_bind_ipv6` (the underlying Ceph daemon config the charm sets when + `prefer-ipv6` is enabled). +- A real caveat quoted from the charm's own docs: "these charms do not + currently support IPv6 privacy extension. In order for this charm to + function correctly, the privacy extension must be disabled and a + non-temporary address must be configured/available on your network + interface." This is a real host/OS-level prerequisite for every ceph-mon + unit's storage/replication interface -- not something an overlay file + can set, needs to be part of Phase-0/node-prep discipline. + +### 4. OVN has NO explicit IPv6/encapsulation charm-config option + +**CONFIRMED**: fetched the FULL `charm-layer-ovn/config.yaml` (the shared +base for `ovn-central`/`ovn-chassis`) -- 25 options total, none related to +IPv6, address binding, or encapsulation IP. geneve-over-v6 for the +data-tenant plane is therefore not a charm-config concern at all; it +follows whichever IP family the unit's bound interface on that plane +actually has. Since data-tenant is ULA-only (no v4 present) per D-101, this +needs no overlay entry -- the absence of an entry IS the correct +configuration, not an oversight. + +### 5. Vault's cert-issuance code has no IPv4/IPv6 distinction + +**CONFIRMED**: fetched `charm-vault/src/lib/charm/vault_pki.py`'s actual +`sort_sans()` function -- it splits SANs into "IP SANs" vs. "name SANs" +using `charmhelpers.contrib.network.ip.is_ip()`, with NO further IPv4/IPv6 +differentiation anywhere in the function or its caller +(`generate_certificate()`, which just joins whatever IP SANs it's given +into a comma-separated string). D-109's "Vault issues v4+IPv6-SAN certs" +requirement is technically supported by the charm's own code path, not +merely assumed. + +### 6. A real, open upstream risk for Octavia's lb-mgmt-net over IPv6 + +**CONFIRMED** (real, still-referenced Launchpad bug reports, not +speculation): #1911788 ("IPv6 mgmt network not working, octavia can't talk +to amphora," OpenStack Octavia Charm) and #1913409 ("octavia_amp_network +does not support IPv6," kolla-ansible, describing the same underlying +Octavia limitation from a different deployment tool). #1911788's root cause +traces to an OVN/LXD/MAAS hostname-resolution mismatch (Neutron's +`binding_host_id` carrying a short hostname while OVN's controller expects +the FQDN) -- it was marked a duplicate of #1896630, "managing /etc/hosts +for containers." That is the SAME CLASS of problem this repo's own D-008 +bootstrap order (static /etc/hosts bootstrap -> os-public-hostname -> vault +certs -> Designate, reactivated by D-106 for VR1) already exists to +harden against -- so this is NOT necessarily a fatal blocker here, but it +IS a real, open, documented upstream risk for exactly the kind of network +(Octavia's amphora management network) D-101 wants to put on ULA-only IPv6. +`overlays/dc-dc-ipv6-family-matrix.yaml` deliberately does NOT attempt an +Octavia lb-mgmt-net IPv6 change for this reason -- that needs its own +explicit decision (accept the risk and test for real once DC1 exists, or +keep Octavia's lb-mgmt-net dual-stack/v4 as a deliberate, logged D-101 +exception), presented here rather than silently forced through. + +## What this closes vs. what remains open + +CLOSES (mechanism): the "no overlay file exists, charm option names +unconfirmed" half of gap #13 -- a real, sourced overlay now exists at +`overlays/dc-dc-ipv6-family-matrix.yaml`, covering 9 of Octavia's 11 sibling +dual-stack API charms directly plus ceph-mon's ULA-only switch, with OVN +correctly requiring no entry. + +STAYS OPEN: (a) the 8 INFERRED-BY-PATTERN charms' `prefer-ipv6` option +needs live `juju config` confirmation once any of them is actually +deployed; (b) the exact VIP-list-position-to-network mapping inside each +charm's context-building code was not traced to source; (c) Octavia's +lb-mgmt-net IPv6 question is a real, open decision, not resolved by this +research; (d) none of this has been applied or tested against a live +model -- UNVALIDATED, same posture as every other OpenTofu/overlay artifact +built this session. diff --git a/overlays/dc-dc-ipv6-family-matrix.yaml b/overlays/dc-dc-ipv6-family-matrix.yaml new file mode 100644 index 0000000..3c3f79e --- /dev/null +++ b/overlays/dc-dc-ipv6-family-matrix.yaml @@ -0,0 +1,169 @@ +# overlays/dc-dc-ipv6-family-matrix.yaml +# +# D-101 IPv6 family-matrix overlay (tooling gap register item #13). +# Researched 2026-07-09/10 against real charm source/config (not memory -- +# see docs/dc-dc-ipv6-charm-research.md for full sourcing, per-charm +# confidence level, and the one significant open risk this overlay does +# NOT attempt to close). Applied ALONGSIDE bundle.yaml's other overlays, +# e.g.: +# juju deploy ./bundle.yaml \ +# --overlay overlays/octavia-pki.yaml \ +# --overlay "overlays/${DC}-hostnames.yaml" \ +# --overlay overlays/dc-dc-ipv6-family-matrix.yaml \ +# -m "${DC_MODEL}" +# +# NOT YET APPLIED to any live model -- authored prep-only, no live cloud +# reachable this session. Every VIP/CIDR value below is an explicit +# {{TOKEN}} placeholder (this repo's established convention, matching +# opentofu/templates/opnsense-config.xml.tmpl) -- render/substitute with +# real, measured per-DC values before use; do not fill in a guessed +# address. +# +# CONFIRMED mechanism, sourced 2026-07-09/10: +# - charms.openstack-family API charms (confirmed directly for +# charm-keystone's config.yaml, and for charm-nova-cloud-controller's +# actual "Dual Stack VIPs" commit) expose a `prefer-ipv6` boolean. When +# True, HAProxy binds BOTH `*:port` (v4, wildcard) AND `:::port` (v6, +# wildcard) SIMULTANEOUSLY -- this is genuinely ADDITIVE dual-stack, not +# an either/or switch, confirmed by reading the actual haproxy.cfg +# Jinja template diff in that commit. The existing `vip:` option (already +# a space-separated multi-network list in this bundle, per D-020's triple- +# VIP pattern) takes the ADDITIONAL v6/GUA VIP literals alongside the +# existing v4 ones once `prefer-ipv6: true` is set. +# - charm-ceph-mon exposes `prefer-ipv6` (bool) + `ceph-public-network` / +# `ceph-cluster-network` (space-delimited CIDR list). Per that charm's own +# docs, `prefer-ipv6=False` (default) means IPv4 is expected -- this +# reads as a straight EITHER/OR switch for ceph-mon specifically (unlike +# the additive HAProxy behavior above), which is actually the CORRECT +# shape for storage/replication: D-101 wants those ULA-ONLY, not +# dual-stack, so a clean switch to v6-only is exactly right here. +# - OVN (ovn-central/ovn-chassis, charm-layer-ovn base) has NO explicit +# IPv6/encapsulation config option at all (confirmed: read the full +# config.yaml, no such key exists). geneve-over-v6 for the data-tenant +# plane is therefore NOT a charm-config concern -- it is governed purely +# by which IP family the unit's bound interface on that plane actually +# has. Since data-tenant is ULA-only (no v4 present) per D-101, the +# geneve tunnel endpoint address will naturally be the unit's v6 address +# with NO overlay entry needed for OVN at all. +# - charm-vault's cert-issuance code (`vault_pki.py`'s `sort_sans()`) +# confirmed to have NO IPv4/IPv6 distinction when building IP SANs -- +# D-109's "Vault issues v4+IPv6-SAN certs" requirement is technically +# supported by the charm's own code, not just assumed. +# +# NOT independently confirmed per-charm (inferred by shared-framework +# pattern only): glance, neutron-api, placement, cinder, barbican, magnum, +# openstack-dashboard, ceph-radosgw all share the same charms.openstack +# base classes as keystone/nova-cloud-controller, so `prefer-ipv6` and the +# additive dual-stack HAProxy behavior is EXPECTED to apply identically -- +# but only keystone's config.yaml and nova-cloud-controller's actual code +# were read directly. Confirm each charm's real `prefer-ipv6` presence via +# `juju config ` once deployed, before assuming this overlay is +# complete for all of them. +# +# ONE SIGNIFICANT OPEN RISK, deliberately NOT addressed by this overlay: +# Octavia's lb-mgmt-net (the amphora management network D-101 wants +# ULA-only) is a NEUTRON tenant network the octavia charm itself creates +# (`create-mgmt-network` option), not a Juju-space-bound interface like +# ceph-mon's -- a fundamentally different mechanism. Real, still-open +# upstream bug reports exist describing IPv6 lb-mgmt-net failures +# (Launchpad #1911788 "IPv6 mgmt network not working, octavia can't talk +# to amphora"; #1913409 "octavia_amp_network does not support IPv6" against +# kolla-ansible, the same underlying Octavia limitation). #1911788's root +# cause traces to an OVN/LXD/MAAS hostname-resolution mismatch (marked +# duplicate of #1896630, "managing /etc/hosts for containers") -- the SAME +# CLASS of problem this repo's own D-008 bootstrap order (static /etc/hosts +# -> os-public-hostname -> vault certs -> Designate) already exists to +# harden against, so it is NOT necessarily fatal here, but it is a REAL, +# documented, open upstream risk, not a solved problem. This overlay +# deliberately does NOT attempt an Octavia lb-mgmt-net IPv6 config change -- +# that needs its own decision (present to the operator: accept the risk and +# test it for real once DC1 exists, or keep Octavia's lb-mgmt-net dual-stack/ +# v4 as a deliberate, logged D-101 exception) rather than being silently +# forced through in an overlay file. + +applications: + # ---- Dual-stack API charms (metal-internal ULA leg + provider-public + # GUA leg, per D-101's family matrix) ---- + keystone: + options: + prefer-ipv6: true + # Existing vip (D-020 triple: provider/metal-admin/metal-internal v4) + # gets the v6/GUA legs appended -- do NOT replace the v4 entries, + # append only. Render with real per-DC measured addresses. + vip: "{{KEYSTONE_VIP_PROVIDER_V4}} {{KEYSTONE_VIP_METAL_ADMIN_V4}} {{KEYSTONE_VIP_METAL_INTERNAL_V4}} {{KEYSTONE_VIP_PROVIDER_GUA}} {{KEYSTONE_VIP_METAL_ADMIN_ULA}} {{KEYSTONE_VIP_METAL_INTERNAL_ULA}}" + + glance: + options: + prefer-ipv6: true + vip: "{{GLANCE_VIP_PROVIDER_V4}} {{GLANCE_VIP_METAL_ADMIN_V4}} {{GLANCE_VIP_METAL_INTERNAL_V4}} {{GLANCE_VIP_PROVIDER_GUA}} {{GLANCE_VIP_METAL_ADMIN_ULA}} {{GLANCE_VIP_METAL_INTERNAL_ULA}}" + + neutron-api: + options: + prefer-ipv6: true + vip: "{{NEUTRON_VIP_PROVIDER_V4}} {{NEUTRON_VIP_METAL_ADMIN_V4}} {{NEUTRON_VIP_METAL_INTERNAL_V4}} {{NEUTRON_VIP_PROVIDER_GUA}} {{NEUTRON_VIP_METAL_ADMIN_ULA}} {{NEUTRON_VIP_METAL_INTERNAL_ULA}}" + + nova-cloud-controller: + options: + prefer-ipv6: true # CONFIRMED: this charm's actual "Dual Stack VIPs" commit is the direct source for this whole overlay's design + vip: "{{NCC_VIP_PROVIDER_V4}} {{NCC_VIP_METAL_ADMIN_V4}} {{NCC_VIP_METAL_INTERNAL_V4}} {{NCC_VIP_PROVIDER_GUA}} {{NCC_VIP_METAL_ADMIN_ULA}} {{NCC_VIP_METAL_INTERNAL_ULA}}" + + placement: + options: + prefer-ipv6: true + vip: "{{PLACEMENT_VIP_PROVIDER_V4}} {{PLACEMENT_VIP_METAL_ADMIN_V4}} {{PLACEMENT_VIP_METAL_INTERNAL_V4}} {{PLACEMENT_VIP_PROVIDER_GUA}} {{PLACEMENT_VIP_METAL_ADMIN_ULA}} {{PLACEMENT_VIP_METAL_INTERNAL_ULA}}" + + cinder: + options: + prefer-ipv6: true + vip: "{{CINDER_VIP_PROVIDER_V4}} {{CINDER_VIP_METAL_ADMIN_V4}} {{CINDER_VIP_METAL_INTERNAL_V4}} {{CINDER_VIP_PROVIDER_GUA}} {{CINDER_VIP_METAL_ADMIN_ULA}} {{CINDER_VIP_METAL_INTERNAL_ULA}}" + + barbican: + options: + prefer-ipv6: true + vip: "{{BARBICAN_VIP_PROVIDER_V4}} {{BARBICAN_VIP_METAL_ADMIN_V4}} {{BARBICAN_VIP_METAL_INTERNAL_V4}} {{BARBICAN_VIP_PROVIDER_GUA}} {{BARBICAN_VIP_METAL_ADMIN_ULA}} {{BARBICAN_VIP_METAL_INTERNAL_ULA}}" + + magnum: + options: + prefer-ipv6: true + vip: "{{MAGNUM_VIP_PROVIDER_V4}} {{MAGNUM_VIP_METAL_ADMIN_V4}} {{MAGNUM_VIP_METAL_INTERNAL_V4}} {{MAGNUM_VIP_PROVIDER_GUA}} {{MAGNUM_VIP_METAL_ADMIN_ULA}} {{MAGNUM_VIP_METAL_INTERNAL_ULA}}" + + openstack-dashboard: + options: + prefer-ipv6: true + vip: "{{DASHBOARD_VIP_PROVIDER_V4}} {{DASHBOARD_VIP_METAL_ADMIN_V4}} {{DASHBOARD_VIP_METAL_INTERNAL_V4}} {{DASHBOARD_VIP_PROVIDER_GUA}} {{DASHBOARD_VIP_METAL_ADMIN_ULA}} {{DASHBOARD_VIP_METAL_INTERNAL_ULA}}" + + ceph-radosgw: + options: + prefer-ipv6: true + vip: "{{RADOSGW_VIP_PROVIDER_V4}} {{RADOSGW_VIP_METAL_ADMIN_V4}} {{RADOSGW_VIP_METAL_INTERNAL_V4}} {{RADOSGW_VIP_PROVIDER_GUA}} {{RADOSGW_VIP_METAL_ADMIN_ULA}} {{RADOSGW_VIP_METAL_INTERNAL_ULA}}" + + # octavia: deliberately NOT included here -- see "ONE SIGNIFICANT OPEN + # RISK" above. Its VIP (metal-admin/metal-internal/provider-public, + # matching the pattern above) COULD take the same prefer-ipv6 + appended- + # VIP treatment for its own API endpoint (that part is no different from + # the other charms above) -- what's genuinely unresolved is its SEPARATE + # lb-mgmt-net (amphora management) IPv6 support, a different mechanism + # entirely. If the operator wants Octavia's API endpoint dual-stacked + # while leaving lb-mgmt-net v4-only as a deliberate exception, add: + # octavia: + # options: + # prefer-ipv6: true + # vip: "{{OCTAVIA_VIP_PROVIDER_V4}} {{OCTAVIA_VIP_METAL_ADMIN_V4}} {{OCTAVIA_VIP_METAL_INTERNAL_V4}} {{OCTAVIA_VIP_PROVIDER_GUA}} {{OCTAVIA_VIP_METAL_ADMIN_ULA}} {{OCTAVIA_VIP_METAL_INTERNAL_ULA}}" + # -- but decide this explicitly, don't silently activate it via this file. + + # ---- ULA-only planes (storage, replication) -- Ceph-over-v6 ---- + ceph-mon: + options: + prefer-ipv6: true # CONFIRMED real option, charm-ceph-mon config.yaml + ceph-public-network: "{{DC_STORAGE_ULA_CIDR}}" + ceph-cluster-network: "{{DC_REPLICATION_ULA_CIDR}}" + # NOTE: prefer-ipv6 privacy-extension caveat (charm's own docs): + # "IPv6 privacy extension... must be disabled and a non-temporary + # address must be configured/available" on every ceph-mon unit's + # storage/replication interface -- a real host/OS-level prerequisite, + # not something this overlay can set. + + # data-tenant (OVN geneve): deliberately NO overlay entry. Confirmed no + # charm-config toggle exists for ovn-central/ovn-chassis; the plane being + # ULA-only (no v4 present, per D-101) is sufficient on its own -- geneve + # encapsulation follows whatever address family the bound interface has. diff --git a/runbooks/dc-dc-phase4-juju-bundle-per-dc.md b/runbooks/dc-dc-phase4-juju-bundle-per-dc.md index 7c14320..5724101 100644 --- a/runbooks/dc-dc-phase4-juju-bundle-per-dc.md +++ b/runbooks/dc-dc-phase4-juju-bundle-per-dc.md @@ -196,11 +196,9 @@ --- -## Step 6 -- Write + apply the IPv6 family-matrix overlay [NOT YET WRITTEN] +## Step 6 -- Write + apply the IPv6 family-matrix overlay [OVERLAY DRAFTED 2026-07-10, NOT YET APPLIED] -**This is real, undone design work -- flagged here rather than glossed -over.** D-101's family matrix (Section 2 of the buildout design) requires, -per DC: +D-101's family matrix (Section 2 of the buildout design) requires, per DC: - `data-tenant`, `storage`, `replication`: IPv6-ONLY ULA (no v4 config at all on these planes for the relevant charms -- e.g. `ceph-mon`'s `public-network`/`cluster-network`, OVN's geneve encapsulation address). @@ -212,29 +210,46 @@ - `provider-public`: DUAL-STACK v4 + GUA (native, no NAT66 -- D-101's tenant/MTU sub-policy folded in from D-102). -**No overlay file implementing this exists yet in this repo.** The exact -Juju charm config option names needed to add v6 addressing to each affected -application (`ceph-mon`, `ovn-central`, `ovn-chassis`, `neutron-api-plugin- -ovn`, `octavia`, the HA-cluster/vip-carrying API charms, etc.) have NOT been -confirmed against those charms' real current config schemas this session -- -inventing plausible-looking option names here would violate this repo's -"never fabricate a flag/option name you haven't verified" norm. Before this -step can actually run: -1. Confirm each affected charm's real config options for v6/dual-stack - addressing (charm's own `config.yaml` in charmhub, or `juju config - ` against a live unit once deployed) -- do not assume symmetry with - the v4 option names. -2. Author a new `overlays/dc-dc-ipv6-family-matrix.yaml` (or per-DC - variants if DC1/DC2 ever need to diverge) implementing the confirmed - options. -3. Apply via `juju deploy ./bundle.yaml --overlay ... --overlay - overlays/dc-dc-ipv6-family-matrix.yaml` (stacked overlays, same pattern - as the existing octavia-pki overlay) OR `juju config =` - per-app post-deploy, whichever the charm options actually require. +**`overlays/dc-dc-ipv6-family-matrix.yaml` now exists**, drafted 2026-07-10 +against REAL charm source/config (not guessed option names) -- see +`docs/dc-dc-ipv6-charm-research.md` for full sourcing and per-charm +confidence level. Summary: `prefer-ipv6` (confirmed real option, additive +dual-stack HAProxy binding, confirmed via `charm-nova-cloud-controller`'s +actual "Dual Stack VIPs" commit) + appended v6/GUA entries on the existing +`vip:` option, for the nine dual-stack API charms directly confirmed or +sharing the same charms.openstack framework; `ceph-mon`'s own separate +`prefer-ipv6` + `ceph-public-network`/`ceph-cluster-network` (a clean +switch-to-v6-only, correct for the ULA-only planes); NO entry for OVN +(confirmed no such charm-config option exists -- geneve family follows the +bound interface automatically once the plane itself is ULA-only). -Log this as its own DOCFIX/design task once the charm-option research is -done -- it blocks this stage's "Ceph-over-v6 and geneve-over-v6 verified" -gate criterion (Step 12) until it exists. +**Apply via** (stacked overlays, same pattern as the existing octavia-pki +overlay): +```bash +juju deploy ./bundle.yaml \ + --overlay overlays/octavia-pki.yaml \ + --overlay "overlays/${DC}-hostnames.yaml" \ + --overlay overlays/dc-dc-ipv6-family-matrix.yaml \ + -m "${DC_MODEL}" --dry-run +``` +Review the diff before applying for real, same discipline as every other +overlay in this repo. + +**Still genuinely open, not resolved by the overlay:** +1. The 8 charms whose `prefer-ipv6` presence is INFERRED-BY-PATTERN (not + individually fetched from their own `config.yaml`) need live `juju + config ` confirmation once first deployed. +2. **Octavia's `lb-mgmt-net` IPv6 support is a real, open risk, not + resolved.** The overlay deliberately excludes an Octavia entry -- + `docs/dc-dc-ipv6-charm-research.md` section 6 documents two real, + still-referenced upstream Launchpad bugs (#1911788, #1913409) about + IPv6 lb-mgmt-net failures. Decide explicitly before this stage's + Ceph-over-v6/geneve-over-v6 gate is declared closed: accept the risk + and test it for real once DC1 exists, or keep Octavia's lb-mgmt-net + v4-only as a deliberate, logged D-101 exception. +3. UNVALIDATED against any live model -- this overlay has not been applied + or tested, same posture as every other artifact from tonight's + prep-only session. ---