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 <app> 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.