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.