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