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