Fork: 0
OpenStack / openstack-caracal-dc-dc
Transfer to URL with SHA Find file
Newer
Older
openstack-caracal-dc-dc / docs / changelog-20260709-designate-cinderbackup-rbdmirror.md
@JANeumatrix JANeumatrix 5 hours ago 7 KB DOCFIX-167: bundle.yaml -- Designate reactivation + D-108 DR mechanism (gaps #6+14)
Raw Blame History

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.