diff --git a/bundle.yaml b/bundle.yaml index 67dce52..b07f248 100644 --- a/bundle.yaml +++ b/bundle.yaml @@ -11,6 +11,11 @@ # Endpoints: IP-ONLY -- os-public-hostname dropped on all API charms; the dual VIPs ARE the # catalog endpoints (public 10.12.4.N / internal+admin 10.12.8.N). Vault issues # per-VIP IP-SAN certs. No control-plane DNS dependency. (B5) +# VR1 DC-DC NOTE (2026-07-10, DOCFIX-167): D-106 reactivates os-public-hostname +# PER-DC via a separate overlay (overlays/${DC}-hostnames.yaml, proposed in +# runbooks/dc-dc-phase6-designate-cos-magnum.md) once Designate exists -- this base +# bundle stays DC-agnostic; B5's IP-only posture is this file's own DEFAULT, only +# overridden per-DC via that overlay, not edited here. # HA chain: hacluster subordinates + dual VIPs + :ha relations ACTIVE for 11 API charms # (10 prior + ceph-radosgw, un-deferred). VIPs front-loaded into the MAAS-reserved # /26: provider 10.12.4.2-.63, metal 10.12.8.2-.63 (supersedes .224-.254). (B1) @@ -42,7 +47,11 @@ D-005 Ceph Squid D-006 Vault HA backend -- REVISED: etcd/easyrsa dropped for testcloud; Raft-vs-etcd is a Roosevelt item (C1) D-007 Magnum Layer A + Layer B graft - D-019 (supersedes D-008) Designate deferred to v2 + D-019 (supersedes D-008) Designate deferred to v2 -- SUPERSEDED 2026-07-10 by D-106 + (VR1 DC-DC reactivation; see designate/designate-bind/designate-hacluster below and + docs/changelog-20260709-designate-cinderbackup-rbdmirror.md, DOCFIX-167). D-019's + text is retained for history per this repo's append-only decision discipline -- the + charms below are the concrete reversal. D-009 hacluster subordinates (decorative on testcloud) D-016 IPv4-only v1 D-018 MAAS-release-direct teardown @@ -512,7 +521,11 @@ osd: storage public: storage radosgw: storage - rbd-mirror: storage + rbd-mirror: replication # corrected 2026-07-10 (D-108, DOCFIX-167): was + # `storage`, inherited unchanged from the VR0/DC0 seed + # (predates D-108) -- cross-DC rbd-mirror daemon traffic + # must ride the IPv6-only ULA replication plane, not the + # intra-DC OSD storage plane. constraints: arch=amd64 # provisions the NIC and sets the Ceph public net. Mons use only the # public net (no cluster binding needed). @@ -759,13 +772,111 @@ channel: 2024.1/stable # ===================================================================== - # HA Cluster Subordinates (11 active for v1: 10 API charms + ceph-radosgw) + # Designate (DNS) -- REACTIVATED 2026-07-10 per D-106 (supersedes D-019's + # v1 deferral, reactivates the original D-008 bootstrap order). Backend + # designate-bind (bind9, lowest-delta Charmed-OpenStack-native backend per + # D-106's own text). Per-DC INDEPENDENT zones once deployed (independent + # Keystones) -- the zone name/A/AAAA population itself is NOT part of this + # bundle; it is Stage 7's own runbook (runbooks/dc-dc-phase6-designate-cos- + # magnum.md), which also proposes the per-DC os-public-hostname overlay + # this reactivation's other coupled change (B5 reversal) depends on. + # Channel matches this bundle's existing Caracal 2024.1 pin (D-002 matrix). + # NOT YET DEPLOYED to any live model -- prep-only repo change, 2026-07-10. + # ===================================================================== + designate: + charm: designate + channel: 2024.1/stable + num_units: 1 + to: [lxd:9] + bindings: + '': metal-admin + dns-backend: metal-internal + identity-service: metal-internal + shared-db: metal-internal + certificates: metal-internal + coordinator-memcached: metal-internal + dnsaas: provider-public # designate's REAL provides-side endpoint name + # (interface "designate") -- confirmed via its + # own metadata.yaml; NOT named "public" like the + # other API charms in this bundle. + ha: metal-internal + constraints: arch=amd64 + + designate-mysql-router: + charm: mysql-router + channel: 8.0/stable + bindings: + '': metal-admin + certificates: metal-internal + db-router: metal-internal + shared-db: metal-internal + + designate-bind: + charm: designate-bind + channel: 2024.1/stable + num_units: 1 + to: [lxd:9] + bindings: + '': metal-admin + dns-backend: metal-internal + constraints: arch=amd64 + + # ===================================================================== + # Cinder-backup + Ceph rbd-mirror -- D-108 cross-DC replication mechanism + # (VR1 DC-DC, added 2026-07-10; tooling gap register item #14). cinder's + # own `backup-backend` binding already existed (metal-internal, unused + # until now); ceph-mon's `rbd-mirror` binding is corrected below from + # `storage` to `replication` in the SAME delivery (D-108 requires the + # cross-DC rbd-mirror daemon traffic ride the IPv6-only ULA replication + # plane, not the intra-DC OSD storage plane -- the old binding predates + # D-108, inherited unchanged from the VR0/DC0 seed at commit 8813efc). + # `cinder-backup` is a SUBORDINATE charm (confirmed: real metadata.yaml + # carries `subordinate: true`, provides ONLY `backup-backend` (interface + # `cinder-backup`, scope: container) + requires `ceph`/`juju-info` -- no + # amqp relation exists on this charm, unlike a principal service) -- no + # num_units/to/constraints, it colocates with `cinder` automatically, + # matching this bundle's existing `cinder-ceph` subordinate shape. + # `ceph-rbd-mirror` IS a principal (confirmed: real metadata.yaml carries + # `subordinate: false`), with TWO requires endpoints on the SAME interface + # (`ceph-rbd-mirror`): `ceph-local` (this DC's own ceph-mon, wired below) + # and `ceph-remote` (the PEER DC's ceph-mon) -- `ceph-remote` is a + # cross-DC, cross-Juju-controller relation (D-104: one independent + # controller per DC) and CANNOT be expressed as a same-bundle relation + # line; it needs either a `juju offer`/`juju consume` cross-model relation + # or (the mechanism `runbooks/dc-dc-phase5-dr-failover-drill.md` already + # documents) the manual `rbd mirror pool peer bootstrap create/import` + # CLI flow -- NOT wired here, flagged rather than invented. + # Single-unit for the principal, matching D-108/D-104's VR1 test economy + # (daemon HA is single-unit for VR1, noted for Roosevelt scale-up). + # NOT YET DEPLOYED to any live model -- prep-only repo change, 2026-07-10. + # ===================================================================== + cinder-backup: + charm: cinder-backup + channel: 2024.1/stable + bindings: + '': metal-admin + ceph: storage + + ceph-rbd-mirror: + charm: ceph-rbd-mirror + channel: squid/stable + num_units: 1 + to: [lxd:10] + bindings: + '': metal-admin + ceph-local: replication + ceph-remote: replication # this DC's own leg only -- see note above; the peer DC's side is NOT this bundle's concern + nrpe-external-master: metal-internal + constraints: arch=amd64 + + # ===================================================================== + # HA Cluster Subordinates (12 active for VR1: 10 v1 API charms + ceph-radosgw + # + designate, reactivated 2026-07-10 per D-106 -- see designate-hacluster below) # ===================================================================== # Channel: 2.4/stable (per Caracal Charm Delivery table, D-002 verified 2026-05-22). # cluster_count: 1 (decorative on single-unit testcloud, D-009 / BUNDLEFIX-003). # VIPs front-loaded into the MAAS-reserved provider/metal /26 per B1 (.2-.63). # vault-hacluster stays commented (vault single-unit on mysql, C1 / BUNDLEFIX-002). - # designate-hacluster stays deferred (D-019). # bindings: '': metal-admin @@ -782,8 +893,8 @@ barbican-hacluster: {charm: hacluster, channel: 2.4/stable, options: {cluster_count: 1}, bindings: {'': metal-admin, ha: metal-internal, hanode: metal-internal, pacemaker-remote: metal-internal, peer-availability: metal-internal}} magnum-hacluster: {charm: hacluster, channel: 2.4/stable, options: {cluster_count: 1}, bindings: {'': metal-admin, ha: metal-internal, hanode: metal-internal, pacemaker-remote: metal-internal, peer-availability: metal-internal}} ceph-radosgw-hacluster: {charm: hacluster, channel: 2.4/stable, options: {cluster_count: 1}, bindings: {'': metal-admin, ha: metal-internal, hanode: metal-internal, pacemaker-remote: metal-internal, peer-availability: metal-internal}} # B1 -- un-deferred + designate-hacluster: {charm: hacluster, channel: 2.4/stable, options: {cluster_count: 1}, bindings: {'': metal-admin, ha: metal-internal, hanode: metal-internal, pacemaker-remote: metal-internal, peer-availability: metal-internal}} # D-106 -- reactivated 2026-07-10, supersedes D-019 deferral # vault-hacluster: { charm: hacluster, channel: 2.4/stable } # C1: vault single-unit on mysql; HA at Roosevelt - # v2-deferred (D-019): designate-hacluster: { charm: hacluster, channel: 2.4/stable } # memcached: nova-cloud-controller token/cell caching (BUNDLEFIX-004) memcached: @@ -873,6 +984,9 @@ - [cinder-ceph:ceph, ceph-mon:client] - [cinder-ceph:ceph-access, nova-compute:ceph-access] - [cinder:ha, cinder-hacluster:ha] + # ---- cinder-backup (D-108, 2026-07-10 -- subordinate, confirmed via real metadata.yaml) + - [cinder-backup:backup-backend, cinder:backup-backend] + - [cinder-backup:ceph, ceph-mon:client] # ---- Ceph mon + osd + radosgw - [ceph-mon:osd, ceph-osd:mon] @@ -882,6 +996,10 @@ - [ceph-radosgw:identity-service, keystone:identity-service] - [ceph-radosgw:certificates, vault:certificates] - [ceph-radosgw:ha, ceph-radosgw-hacluster:ha] # B1 -- un-deferred + # ---- ceph-rbd-mirror (D-108, 2026-07-10) -- ceph-local only; ceph-remote + # (the peer DC's ceph-mon) is a cross-model relation, NOT wired here -- see + # the app-block comment above. + - [ceph-rbd-mirror:ceph-local, ceph-mon:rbd-mirror] # ---- OpenStack Dashboard (Horizon) - [dashboard-mysql-router:db-router, mysql-innodb-cluster:db-router] @@ -926,3 +1044,19 @@ - [magnum:certificates, vault:certificates] - [magnum-dashboard:dashboard, openstack-dashboard:dashboard-plugin] - [magnum:ha, magnum-hacluster:ha] + + # ---- Designate (DNS) -- D-106, 2026-07-10. dns-backend/ha/coordinator- + # memcached endpoint names CONFIRMED via charm-designate's real + # metadata.yaml; 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, not independently + # re-fetched for designate specifically -- flag if `juju deploy --dry-run` + # disagrees). + - [designate-mysql-router:db-router, mysql-innodb-cluster:db-router] + - [designate-mysql-router:shared-db, designate:shared-db] + - [designate:identity-service, keystone:identity-service] + - [designate:amqp, rabbitmq-server:amqp] + - [designate:certificates, vault:certificates] + - [designate:coordinator-memcached, memcached:cache] + - [designate:dns-backend, designate-bind:dns-backend] + - [designate:ha, designate-hacluster:ha] diff --git a/docs/changelog-20260709-designate-cinderbackup-rbdmirror.md b/docs/changelog-20260709-designate-cinderbackup-rbdmirror.md new file mode 100644 index 0000000..8cbbc82 --- /dev/null +++ b/docs/changelog-20260709-designate-cinderbackup-rbdmirror.md @@ -0,0 +1,134 @@ +# 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. diff --git a/runbooks/dc-dc-phase5-dr-failover-drill.md b/runbooks/dc-dc-phase5-dr-failover-drill.md index 79ba623..78bcff5 100644 --- a/runbooks/dc-dc-phase5-dr-failover-drill.md +++ b/runbooks/dc-dc-phase5-dr-failover-drill.md @@ -75,9 +75,15 @@ it, correct it as its own gated bundle-relation-binding change, do not silently leave the cross-DC daemon traffic on the wrong plane. -None of the three above are fixed by writing this document -- there is no live Ceph cluster -this session to test a bundle change against (2026-07-09/10 is PREP-ONLY). They are Step 1's -first checks and Step 2's first gated mutations when this runbook is actually run. +**UPDATE 2026-07-10 (DOCFIX-167):** `bundle.yaml` ITSELF now carries `cinder-backup`, +`ceph-rbd-mirror`, and the corrected `rbd-mirror: replication` binding (see +`docs/changelog-20260709-designate-cinderbackup-rbdmirror.md`) -- so any DC deployed via +Stage 5's runbook AFTER this date gets all three from the initial `juju deploy`, and Step 1's +CHECK below should find them already correct (skip straight to Step 3). Step 2 remains here, +unmodified, for the case this runbook is run against a DC deployed from an OLDER bundle.yaml +snapshot (pre-2026-07-10) that predates this fix -- do not assume Step 2 is dead code just +because a fresh deploy no longer needs it. Still not live-tested: no Ceph cluster exists this +session (2026-07-09/10 is PREP-ONLY) to confirm either path actually works end-to-end. --- @@ -616,18 +622,36 @@ commits, not secrets. - [ ] `docs/session-ledger.md` updated with the outcome. - [ ] `docs/dc-dc-deployment-workflow.md` Stage 6 row and tracker table updated (Step 12). -- [ ] **Follow-up, NOT built now:** once this drill has been run manually at least once - end-to-end, the radosgw multisite / rbd-mirror command sequences above (Steps 4, 5, 8, - 10.2, 10.3, 11.2-11.4) are strong candidates for extraction into real `scripts/` with a - `tests//run-tests.sh` harness (closing Tooling gap register item #5 for real, not - just documenting the gap). Out of scope for THIS deliverable -- there is no live Ceph - cluster this session to test a script against, and this task was scoped as - runbook-authoring only. Log this as a follow-up item in `docs/session-ledger.md`, not as - a TODO buried in this file. +- [x] **Extraction DONE 2026-07-09 (DOCFIX-165), not future work anymore.** The radosgw + multisite / rbd-mirror command sequences above (Steps 4, 5, 8, 10.2, 11.2-11.4) are now + real, callable, parameterized scripts, closing Tooling gap register item #5's MECHANISM + half: `scripts/dc-dc-radosgw-multisite.sh` (`master-init`/`join-readonly`/ + `enable-two-way` -- Steps 4 and 8's radosgw half), `scripts/dc-dc-rbd-mirror.sh` + (`bootstrap-primary`/`bootstrap-secondary --direction rx-only|rx-tx` -- Steps 5 and 8's + rbd-mirror half), and `scripts/dc-dc-dr-drill.sh` (`failover` -- Step 10.2's force-promote + + a flagged, never-auto-executed Glance re-registration reminder; `failback` -- Steps + 11.2-11.4, with the demote-CURRENT-PRIMARY-before-promote-RECOVERING ordering HARD-CODED + as fixed call order, not left to documentation). Every name/endpoint/unit is a REQUIRED + argument (no invented defaults); default mode is `--dry-run`, `--apply` executes one + command at a time via `juju ssh`/`juju run`, aborting on first failure. Matching harnesses + `tests/dc-dc-radosgw-multisite/`, `tests/dc-dc-rbd-mirror/`, `tests/dc-dc-dr-drill/` + (19/19, 19/19, 23/23 PASS) validate ONLY these scripts' own argument parsing, guard + clauses, and dry-run output (including the failback step ORDER) -- they do NOT and + CANNOT validate real radosgw/rbd-mirror behavior; no live Ceph cluster exists this session + to run any of this against (still true tonight, unchanged from when this item was first + logged). When this runbook is actually executed, Steps 4/5/8/10.2/11.2-11.4 above call + these scripts (starting in `--dry-run` to review the exact plan first) instead of typing + the command sequences by hand. See `docs/changelog-20260709-ceph-replication- + tooling.md`. - [ ] The per-image Glance re-registration mechanism (Step 10.2) and the Cinder - backup/restore-with-metadata reconciliation (Step 10.3/11.3) are the least-scripted, - most manual parts of the drill -- flag both as the highest-value future automation - targets if gap #5 is picked up. + backup/restore-with-metadata reconciliation (Step 10.3/11.3) remain the least-scripted, + most manual parts of the drill even after the above extraction -- `dc-dc-dr-drill.sh + failover` deliberately prints the re-registration step as a flagged MANUAL reminder + rather than executing it (the runbook is explicit the exact invocation depends on + unconfirmed Glance driver behavior), and `failback`'s Step 11.3 Cinder reconciliation is + not scripted at all (tenant/volume-specific). Both remain the highest-value future + automation targets if gap #5 is picked up again after a real drill run surfaces the + concrete Glance driver invocation and a general Cinder reconciliation shape. ## Next Stage 7 -- Designate, COS, Magnum/CAPI (per DC). diff --git a/runbooks/dc-dc-phase6-designate-cos-magnum.md b/runbooks/dc-dc-phase6-designate-cos-magnum.md index f06f311..53541fa 100644 --- a/runbooks/dc-dc-phase6-designate-cos-magnum.md +++ b/runbooks/dc-dc-phase6-designate-cos-magnum.md @@ -239,66 +239,30 @@ already uses. This is a proposed pattern, not yet reviewed -- present it at the same review gate as the rest of Step 1, do not silently adopt it. -### 1.5 -- The application/relation shape (template -- CONFIRM before writing it live) +### 1.5 -- The application/relation shape (DONE 2026-07-10 -- bundle.yaml already carries this) -The block below is a STARTING TEMPLATE only. The exact channel and the exact -relation/binding names are NOT verified against this repo's pinned Charmhub -revisions this session -- confirm both via `scripts/preflight.sh`'s Charmhub -channel assert (the same mechanism that already gates every other charm in -this bundle) before this goes into a real commit: +**This step is CLOSED, not a template anymore.** `bundle.yaml` now carries +real `designate`/`designate-bind`/`designate-mysql-router`/`designate- +hacluster` application blocks + 8 relations, researched directly against +`charm-designate`'s real `metadata.yaml` (not the standard-pattern guess +this runbook originally sketched here). Two things this runbook's first +draft got wrong were caught and fixed during that research, worth knowing +before you run `--dry-run`: +- Designate's real provides-side endpoint is `dnsaas` (interface + `designate`), **not** `public` like the other API charms in this bundle. +- `dns-backend` (interface `bind-rndc`), `ha` (interface `hacluster`), and + `coordinator-memcached` (interface `memcache`, relating to the existing + `memcached` principal) were all confirmed from the charm's own source. + `shared-db`/`identity-service`/`amqp`/`certificates` still follow the + standard pattern (very high confidence, matches 10 other charms) but + were NOT individually re-fetched for designate -- confirm with + `juju deploy --dry-run` before treating this as fully final. -```yaml - designate: - charm: designate - channel: 2024.1/stable # CONFIRM against Charmhub -- matches this - # bundle's D-002 channel matrix pattern for - # every other Caracal API charm; not yet - # independently verified for designate. - num_units: 1 - options: - # os-public-hostname etc. as needed once the DC-specific overlay (1.4) - # is drafted -- do not hardcode a zone/fqdn literal here. - bindings: - '': metal-admin - identity-service: metal-internal - shared-db: metal-internal - dns-backend: metal-internal - public: provider-public - # CONFIRM these binding/relation endpoint names against the designate - # charm's actual metadata.yaml -- written here from the standard - # Charmed OpenStack pattern (identity-service / shared-db / dns-backend), - # not from a live read of this repo's pinned revision. - - designate-bind: - charm: designate-bind - channel: 2024.1/stable # CONFIRM, as above - num_units: 1 - bindings: - '': metal-admin - dns-backend: metal-internal - - designate-mysql-router: - charm: mysql-router - channel: 8.0/stable # matches every other *-mysql-router in this bundle - bindings: - '': metal-admin - db-router: metal-internal - shared-db: metal-internal - - # un-comment and activate (currently deferred at bundle.yaml's HA-subordinates block): - designate-hacluster: - charm: hacluster - channel: 2.4/stable - options: {cluster_count: 1} - bindings: {'': metal-admin, ha: metal-internal, hanode: metal-internal, - pacemaker-remote: metal-internal, peer-availability: metal-internal} -``` -Relations to add (mirroring the existing pattern for every other clustered API -charm in this bundle -- `keystone:identity-service`, the charm's own -`:shared-db` to its mysql-router, `:certificates` to vault, `:ha` to its -hacluster subordinate, plus `designate:dns-backend - designate-bind:dns-backend`). -Do not copy these blindly -- diff against an actual `juju deploy --dry-run` on -a real DC before treating this as final. +See `docs/changelog-20260709-designate-cinderbackup-rbdmirror.md` for the +full record. What's still genuinely open: the `os-public-hostname` overlay +(Step 1.4 above) -- `bundle.yaml` deliberately stays DC-agnostic, so that +overlay is still this runbook's own job at real execution time, not +pre-built. **CHECK (read-only) -- jumphost, once bundle.yaml + overlays are edited** ```bash