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