# Changelog 2026-07-10 -- bundle.yaml: Designate reactivation + D-108 DR mechanism (DOCFIX-167) No live infrastructure touched -- `bundle.yaml` is a repo source file; no `juju deploy`/`juju add-relation` was run against any live model tonight (no live cloud reachable this session). This closes tooling gap register items #6 (Designate reactivation is a bundle change) and #14 (three real `bundle.yaml` gaps for D-108's DR mechanism). **Why this file, specifically, is high-stakes and was handled with extra care:** `bundle.yaml` is not a DC-DC-only artifact -- it is the SAME file this repo's jumphost operations use against the live VR0/DC0 rehearsal cloud (per `CLAUDE.md`: "Commands here reach the real cloud"). Editing it changes what a future `juju deploy ./bundle.yaml` would do against ANY model, not just a not-yet-created DC1/DC2. D-106 and D-108 are both ADOPTED (Stage 0, 2026-07-09), so this reactivation is authorized in principle -- exactly what tooling gap #6 said still needed doing ("editing `bundle.yaml` itself... in addition to writing the reactivation runbook"). This delivery is a REPO-level source change only; before any live `juju deploy`/`juju add-relation` against an actual model (existing VR0/DC0 or a future DC1/DC2), run `bash scripts/preflight.sh` and review the diff with `juju deploy ./bundle.yaml --dry-run` first, per this repo's own standing discipline -- do not treat this changelog as authorization to apply live. ## Items ### 1. Designate reactivation (D-106, supersedes D-019) Added `designate`, `designate-bind`, `designate-mysql-router`, and `designate-hacluster` application blocks + 8 relations, all researched against REAL charm metadata (`raw.githubusercontent.com/openstack/charm- designate/master/src/metadata.yaml`, fetched directly), not guessed: - **Found and corrected a real mistake in the first draft during self- review**: Designate's actual provides-side endpoint is named `dnsaas` (interface `designate`), NOT `public` like every other API charm in this bundle. The first draft used `public: provider-public` by pattern- matching the other 10 charms; caught by checking designate's own metadata.yaml directly before finalizing, corrected to `dnsaas: provider-public`. - Confirmed via source: `dns-backend` (interface `bind-rndc`, relates to `designate-bind`), `ha` (interface `hacluster`), `coordinator-memcached` (interface `memcache`, relates to the existing `memcached` principal). - `shared-db`/`identity-service`/`amqp`/`certificates` follow the SAME standard names every other charms.openstack-family charm in this bundle already uses successfully -- pattern-matched (very high confidence given 10 other charms confirm the pattern), not independently re-fetched for designate specifically. Flagged in the bundle's own inline comment; verify with `juju deploy --dry-run` before a real apply. - Updated the bundle's top header: the `D-019 ... Designate deferred to v2` line now states it is SUPERSEDED 2026-07-10 by D-106 (D-019's text retained per this repo's append-only decision discipline -- not deleted). The `HA Cluster Subordinates` count comment corrected from 11 to 12. - **Deliberately NOT done here**: `os-public-hostname` re-activation on the 11 clustered API charms (D-106's OTHER coupled change, reversing the bundle's B5 IP-only posture) -- per `runbooks/dc-dc-phase6-designate- cos-magnum.md`'s own proposal, this is DC-specific (embeds `dc1`/`dc2` in the hostname) and belongs in a new per-DC overlay (`overlays/${DC}-hostnames.yaml`), NOT this shared, DC-agnostic bundle. A new header comment states this explicitly so a future reader isn't confused about why B5's own line still says "IP-ONLY." ### 2. D-108 DR mechanism: cinder-backup + ceph-rbd-mirror Added `cinder-backup` and `ceph-rbd-mirror` application blocks + 2 relations, and corrected `ceph-mon`'s `rbd-mirror` binding. - **Found and corrected two real mistakes in the first draft via source research, not guessed:** 1. `cinder-backup` is a SUBORDINATE charm (confirmed: `charm-cinder-backup`'s real `metadata.yaml` carries `subordinate: true`, provides only `backup-backend` with `scope: container`, requires `ceph` + `juju-info` -- NO `amqp` relation exists on this charm at all). The first draft gave it `num_units`/`to`/`constraints` and an `amqp` binding as if it were a principal -- all removed; corrected to a bare subordinate block matching this bundle's existing `cinder-ceph` shape. 2. `ceph-rbd-mirror` IS a principal (confirmed: real `metadata.yaml` carries `subordinate: false`) with TWO requires endpoints on the SAME `ceph-rbd-mirror` interface: `ceph-local` and `ceph-remote`. The first draft used a single invented `ceph-rbd-mirror:` binding key that does not exist on the real charm; corrected to the real `ceph-local`/`ceph-remote` endpoint names. - **A genuine, unresolved cross-DC wiring limit, documented rather than worked around**: `ceph-remote` is meant to relate to the PEER DC's ceph-mon -- but D-104 gives each DC its own independent Juju controller, so a same-bundle relation line cannot express this (Juju relations are intra-model). Only `ceph-rbd-mirror:ceph-local -> ceph-mon:rbd-mirror` (this DC's own leg) is wired. The cross-DC peer relationship is EITHER a `juju offer`/`juju consume` cross-model relation OR (the mechanism `runbooks/dc-dc-phase5-dr-failover-drill.md` already documents in full) the manual `rbd mirror pool peer bootstrap create/import` CLI flow -- documented in the bundle's own comment rather than invented as a fake relation line. - `ceph-mon`'s `rbd-mirror` binding corrected from `storage` to `replication` (D-108 requires the cross-DC rbd-mirror daemon traffic ride the IPv6-only ULA replication plane; the old binding predates D-108, inherited unchanged from the VR0/DC0 seed at commit 8813efc -- this is the exact finding `runbooks/dc-dc-phase5-dr-failover-drill.md`'s "Known gaps" section already surfaced, now actually fixed). ## Verification - `python3 -c "import yaml; yaml.safe_load(open('bundle.yaml'))"` -- parses cleanly. 56 applications (was 52), 108 relations (was up from the baseline; net +10 for the two new service groups). Confirmed all five new application names present and `ceph-mon`'s `rbd-mirror` binding now reads `replication`. - `bash scripts/repo-lint.sh`: 0 fail, 1 documented legacy warn (unchanged). - `python3 scripts/provider-bundle-check.py`: **PASS**, all six existing invariants still hold unchanged (11 charms bind public->provider-public, none on provider-vip; 11 clustered VIP triples, octet 50-60; all 4 ovn- chassis chassis MACs present; 108 relations well-formed; mysql-innodb- cluster num_units=3; keystone policyd-override wired) -- confirms the new applications did NOT disturb any existing invariant this repo's own gate already checks. Designate correctly does NOT appear in the VIP-triple count (it uses `dnsaas`/DNS-native addressing, not an HAProxy VIP, so 11 stays 11 -- expected, not a gap in the new work). `tests/provider-bundle-check/run-tests.sh`: 8/8 PASS (unaffected). REVERT: `git checkout HEAD~ -- bundle.yaml` (safe -- no live model has this bundle applied yet this session; reverts to the pre-reactivation state exactly, including B5's original IP-only posture and D-019's original un-superseded text). ## Next actionable step The `os-public-hostname` per-DC overlay (`overlays/${DC}-hostnames.yaml`) this reactivation's OTHER coupled change depends on is not yet authored -- that is Stage 5's own runbook's job at real execution time, not this delivery's. Before any live apply: independently verify the pattern- matched Designate relations (`shared-db`/`identity-service`/`amqp`/ `certificates`) via `juju deploy ./bundle.yaml --dry-run` against a real MAAS/Juju environment, since they were not individually re-confirmed from designate's own metadata.yaml the way the DNS-specific and D-108 endpoints were.