diff --git a/bundle.yaml b/bundle.yaml index b07f248..5f61cdb 100644 --- a/bundle.yaml +++ b/bundle.yaml @@ -16,9 +16,12 @@ # 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) +# HA chain: hacluster subordinates + :ha relations ACTIVE for 12 charms (10 v1 API charms + +# ceph-radosgw, un-deferred, + designate, reactivated 2026-07-10 per D-106) -- of +# these, 11 carry the dual-VIP pattern (designate uses its own dnsaas/DNS-native +# addressing, not an HAProxy VIP, so it doesn't add to the VIP-triple count). VIPs +# front-loaded into the MAAS-reserved /26: provider 10.12.4.2-.63, metal +# 10.12.8.2-.63 (supersedes .224-.254). (B1) # Vault: single unit, MYSQL storage backend (via vault-mysql-router). etcd + easyrsa # REMOVED -- the etcd backend was never used (live storage = mysql) and is moot at # 1 unit; HA backend (Raft vs etcd) is a Roosevelt rehearsal item. (C1; revises D-006) @@ -676,15 +679,21 @@ image-format: raw # B4 -- RAW, not the qcow2 default: glance is Ceph-backed, and the charm # + Ceph docs recommend raw so RBD can fast-clone the amphora (qcow2 # forces a convert-on-import and defeats CoW). - - # ===================================================================== - # Secrets: Barbican - # ===================================================================== - bindings: '': metal-admin certificates: metal-internal identity-credentials: metal-internal + + # ===================================================================== + # Secrets: Barbican + # ===================================================================== + # FIXED 2026-07-10 (full-project sweep): this section header comment + # previously sat BEFORE octavia-diskimage-retrofit's own trailing bindings + # block above (a cosmetic misplacement, not a functional bug -- YAML always + # attached that block to octavia-diskimage-retrofit correctly regardless of + # where the comment sat). Moved here, immediately before barbican itself, + # to stop it visually implying the bindings above belong to Barbican. + barbican: charm: barbican channel: 2024.1/stable @@ -718,6 +727,11 @@ barbican-vault: charm: barbican-vault channel: 2024.1/stable + bindings: + '': metal-admin + certificates: metal-internal + secrets: metal-internal + secrets-storage: metal-internal # ===================================================================== # Kubernetes-as-a-Service: Magnum (Layer A -- CAPI graft is Layer B) @@ -731,12 +745,12 @@ # 4. kubeconfig at /etc/magnum/kubeconfig (server = the mgmt FIP) (phase-07) # 5. magnum trustee domain-setup (REQUIRED; D-046); per-cluster app-creds are # minted by magnum at cluster-create -- NO static capo user/app-cred (D-039) + # FIXED 2026-07-10 (full-project sweep): this section header, and its NOTE, + # previously sat BEFORE barbican-vault's own trailing bindings block above (a + # cosmetic misplacement -- YAML always attached that block to barbican-vault + # correctly regardless of comment position). Moved here, immediately before + # magnum itself. - bindings: - '': metal-admin - certificates: metal-internal - secrets: metal-internal - secrets-storage: metal-internal magnum: charm: magnum channel: 2024.1/stable @@ -770,6 +784,18 @@ magnum-dashboard: charm: magnum-dashboard channel: 2024.1/stable + bindings: + '': metal-admin + dashboard: metal-internal + # FIXED 2026-07-10 (full-project sweep): this app previously had NO bindings + # block at all -- a pre-existing gap (present since the D-052 explicit-bindings + # commit, not introduced tonight), violating this bundle's own stated + # discipline ("explicit per-application blocks, no anchors"). Confirmed via + # the real charm-magnum-dashboard metadata.yaml: subordinate, ONLY a `dashboard` + # (interface dashboard-plugin) requires endpoint -- no `certificates` endpoint + # exists on this charm (unlike octavia-dashboard, its closest sibling in this + # bundle, which does have one), so this block is deliberately minimal, not a + # partial copy of octavia-dashboard's shape. # ===================================================================== # Designate (DNS) -- REACTIVATED 2026-07-10 per D-106 (supersedes D-019's diff --git a/docs/changelog-20260710-sweep-bundle-fixes.md b/docs/changelog-20260710-sweep-bundle-fixes.md new file mode 100644 index 0000000..5ead97f --- /dev/null +++ b/docs/changelog-20260710-sweep-bundle-fixes.md @@ -0,0 +1,81 @@ +# Changelog 2026-07-10 -- Full-project sweep: bundle.yaml fixes (DOCFIX-172) + +No live infrastructure touched -- `bundle.yaml` is a repo source file; no +`juju deploy`/`juju add-relation` was run against any live model. Part of +the full-project sweep (see DOCFIX-170 for overall scope). A dedicated +agent audited the ~50 applications NOT touched by tonight's earlier +DOCFIX-167 edit, since that edit only added/verified the 5 new charms. + +## Items + +### 1. DOCFIX-172a -- `magnum-dashboard` had NO `bindings:` block at all +FILE: `bundle.yaml`. + +WHAT: a real, CONFIRMED pre-existing bug -- `git log -p` shows this +application has had no `bindings:` block since the D-052 explicit-bindings +commit, and every commit since (NOT introduced by tonight's DOCFIX-167 +work). Every other application in this file, including its closest sibling +`octavia-dashboard`, gets an explicit bindings block, per the file's own +stated top-of-file discipline ("explicit per-application blocks, no +anchors"). Without one, `magnum-dashboard`'s endpoints fall to the model's +implicit default space instead of a deliberate plane -- a real risk on a +model whose default space isn't routable to the app's LXD container. + +Fixed with a MINIMAL block, confirmed against the real `charm-magnum- +dashboard` metadata.yaml (fetched directly, not assumed from +`octavia-dashboard`'s shape): this charm is a subordinate with ONLY a +`dashboard` (interface `dashboard-plugin`) requires endpoint -- no +`certificates` endpoint exists on it (unlike `octavia-dashboard`, which +does have one). The fix is `'': metal-admin, dashboard: metal-internal`, +not a copy-paste of `octavia-dashboard`'s fuller block. + +### 2. DOCFIX-172b -- two section-header comments misplaced (cosmetic, confirmed harmless) +FILE: `bundle.yaml`. + +WHAT: the "# Secrets: Barbican" and "# Kubernetes-as-a-Service: Magnum" +section-header comments each sat BEFORE a `bindings:` block that YAML +actually attaches to the PRECEDING application (`octavia-diskimage- +retrofit` and `barbican-vault` respectively), not the app the comment +announces. Confirmed via `yaml.safe_load` that both bindings blocks +attached to the correct (preceding) app both before and after this fix -- +this was purely a visual/formatting issue, not a functional bug. Fixed by +relocating each comment block to immediately precede the app it actually +describes, removing the future-edit risk (a reader could plausibly +mistake the bindings block for belonging to the announced app and edit the +wrong one). + +### 3. DOCFIX-172c -- header VIP/HA-chain count staleness +FILE: `bundle.yaml`. + +WHAT: the top-of-file "HA chain" comment still read "ACTIVE for 11 API +charms (10 prior + ceph-radosgw, un-deferred)" -- stale since DOCFIX-167 +added `designate-hacluster` as a 12th hacluster-subordinate charm (a +different, newer comment block elsewhere in the file already correctly +said 12). Fixed to state 12 charms carry `:ha` relations, of which 11 +still carry the dual/triple-VIP pattern (designate uses its own +`dnsaas`/DNS-native addressing, not an HAProxy VIP, so it doesn't add to +that specific count) -- both the corrected the 12-count and the +still-accurate 11-VIP-count are now stated together, avoiding a NEW +staleness by conflating the two different numbers. + +## Verification + +`python3 -c "import yaml; yaml.safe_load(open('bundle.yaml'))"`: parses +clean, 56 applications / 108 relations unchanged from before this delivery +(these fixes don't add/remove any application or relation, only fix an +existing one's bindings + move comments + correct prose). `python3 +scripts/provider-bundle-check.py`: PASS, all 6 invariants unaffected +(confirmed the corrected `magnum-dashboard` bindings don't disturb the +"11 charms bind public->provider-public" or "11 clustered VIP triples" +counts, since `dashboard`/`''` aren't `public`/`vip`). `bash scripts/ +repo-lint.sh`: 0 fail, 1 documented legacy warn. + +REVERT: `git checkout HEAD~ -- bundle.yaml` (safe -- no live model has +this bundle applied yet). + +## Next actionable step + +None of these three fixes require any downstream runbook update -- +`magnum-dashboard`'s corrected bindings are exactly what a fresh deploy +would need going forward; no runbook asserted a specific (wrong) binding +for it that would now need correcting to match.