diff --git a/docs/changelog-20260710-phase01-bundle-staleness-fix.md b/docs/changelog-20260710-phase01-bundle-staleness-fix.md new file mode 100644 index 0000000..d37f5c6 --- /dev/null +++ b/docs/changelog-20260710-phase01-bundle-staleness-fix.md @@ -0,0 +1,59 @@ +# Changelog 2026-07-10 -- phase-01-bundle-deploy.md: stale bundle expectations fixed (DOCFIX-169) + +No live infrastructure touched -- runbook doc fix only. Found during a +full-project sweep for errors/architectural problems, requested +immediately after the seven gap-closure commits (DOCFIX-162 through 168). + +## Item + +### 1. DOCFIX-169 -- `runbooks/phase-01-bundle-deploy.md` stale post-DOCFIX-167 expectations +FILE: `runbooks/phase-01-bundle-deploy.md`. + +WHAT: `bundle.yaml`'s DOCFIX-167 edit (Designate reactivation + D-108 DR +mechanism, earlier tonight) changed the SAME shared bundle file this +existing, LIVE-CLOUD-relevant VR0 runbook deploys -- but that edit did not +update this runbook's own documented expectations at the time. Found while +sweeping for cascading effects of tonight's changes: + +- **"expected plan: 50 apps, 97 relations"** (Step 1.2's dry-run GATE, the + Constants section, and the historical "As-built reference") was stale -- + the real current count is 56 apps / 108 relations (confirmed via + `python3 -c "import yaml; ..."`). Fixed the two LIVE-GATE references + (Constants section, Step 1.2's GATE); the "As-built reference (2026-06-03 + second redeploy)" section's `50 apps / 97 relations` line was LEFT + UNCHANGED -- it is a historical audit-trail record of a specific past + deploy, and this repo's discipline treats as-built records as append-only + history, not something to retroactively edit. +- **"NO designate (D-019)"** (Step 1.2's GATE) was flatly wrong post- + DOCFIX-167 -- corrected to state designate/designate-bind/designate- + mysql-router/designate-hacluster and cinder-backup/ceph-rbd-mirror are + now present, while `vault:ha` remains correctly absent (unchanged). +- **A real, unresolved architectural tension flagged, not decided:** this + bundle is used for BOTH a plain VR0/DC0 single-DC rehearsal redeploy AND + standing up VR1's DC1 (per the buildout design's own framing -- VR0's + testcloud IS becoming DC1, not staying separate). Reactivating Designate/ + the DR mechanism in the shared file means ANY future `phase-01` run gets + these new charms now, regardless of which intent the operator has. Added + a `!!!` callout stating this plainly -- if a plain VR0-only redeploy + without these charms is ever needed, that requires an explicit decision + (a bundle fragment/override), not a silent assumption either way. +- **EXIT GATE's "waiting on vault certs" list extended, clearly labeled + unconfirmed:** `designate`/`designate-bind` have a `certificates: + metal-internal` relation to vault, so by the same pattern as the + existing list entries they are LIKELY also waiting on vault certs + pre-init -- inferred from the relation graph, NOT confirmed against a + real deploy (no live cloud reachable this session). Flagged explicitly + as not-yet-observed rather than asserted as fact. + +VERIFIED: `bash scripts/repo-lint.sh` 0 fail, 1 documented legacy warn. +This is a doc-only fix; no script/bundle logic changed (`bundle.yaml` +itself is unchanged by this delivery, only this runbook's prose). + +REVERT: `git checkout HEAD~ -- runbooks/phase-01-bundle-deploy.md` (safe). + +## Next actionable step + +This finding is the first result of a broader full-project sweep now +underway (looking for other cascading effects of tonight's bundle.yaml +edit, and any other latent architectural/consistency problems across the +whole repo, not just tonight's own deliverables). diff --git a/docs/session-ledger.md b/docs/session-ledger.md index ae293cf..b07772e 100644 --- a/docs/session-ledger.md +++ b/docs/session-ledger.md @@ -1350,6 +1350,30 @@ 0 fail, 1 documented legacy warn. No live infrastructure touched. Uncommitted -- orchestrating session will assign the real DOCFIX number at integration time. +- **DONE -- Full-project sweep for errors/architectural problems, requested + after the seven gap-closure commits: FIRST finding, fixed (changelog + `docs/changelog-20260710-phase01-bundle-staleness-fix.md`, DOCFIX-169):** + `runbooks/phase-01-bundle-deploy.md` -- an EXISTING, LIVE-CLOUD-relevant + VR0 runbook, not a DC-DC artifact -- had gone stale the moment DOCFIX-167 + edited the SAME shared `bundle.yaml` it deploys. Its "expected plan: 50 + apps, 97 relations" (Constants section + Step 1.2's dry-run GATE) was + wrong (real count now 56/108); its GATE's "NO designate (D-019)" text + flatly contradicted the new reality. Fixed both LIVE-gate references; + deliberately left the historical "As-built reference (2026-06-03)" + section's own `50 apps/97 relations` line UNCHANGED (append-only audit- + trail discipline -- it documents a real past deploy, not something to + retroactively edit). Flagged a real, unresolved architectural tension + rather than silently picking a side: this bundle now serves BOTH a plain + VR0-only redeploy AND standing up DC1, and reactivating Designate/the DR + mechanism in the shared file means any future `phase-01` run gets them + regardless of intent -- a future plain-VR0 redeploy needing to exclude + them would need an explicit override, not an assumption either way. + Extended the EXIT GATE's "waiting on vault certs" list to include + designate/designate-bind (inferred from their real `certificates` + relation to vault, clearly labeled NOT YET OBSERVED against a live + deploy). `bash scripts/repo-lint.sh`: 0 fail, 1 documented legacy warn. + Sweep continues across the rest of the repo (scripts, other runbooks, + OpenTofu modules, test quality, security/secrets posture). diff --git a/runbooks/phase-01-bundle-deploy.md b/runbooks/phase-01-bundle-deploy.md index 0f397ba..8f1ebc5 100644 --- a/runbooks/phase-01-bundle-deploy.md +++ b/runbooks/phase-01-bundle-deploy.md @@ -4,10 +4,26 @@ machines, and verify it settles to the expected PRE-vault-init state (zero errors, vault awaiting init, the TLS consumers awaiting vault certs). Vault init is phase-02. -Decisions: B5 (IP-only), D-019 (no designate), D-020 (dual provider+metal VIPs), -R14 (VIPs front-loaded to .50-.60), Section-G NIC bindings. Troubleshooting: -appendix-A -- R14 (VIP relocation), R15 (.10 phantom resolver), L1 (no `set -e` on -count-gate blocks), L3 (metal-side dual-VIP eyeball check), DOCFIX-016 (maas list leak). +Decisions: B5 (IP-only), D-019 (no designate -- SUPERSEDED 2026-07-10 by D-106, +see the callout below), D-020 (dual provider+metal VIPs), R14 (VIPs front-loaded +to .50-.60), Section-G NIC bindings. Troubleshooting: appendix-A -- R14 (VIP +relocation), R15 (.10 phantom resolver), L1 (no `set -e` on count-gate blocks), +L3 (metal-side dual-VIP eyeball check), DOCFIX-016 (maas list leak). + +!!! `bundle.yaml` CHANGED 2026-07-10 (DOCFIX-167, VR1 DC-DC buildout, D-106/ + D-108 both ADOPTED): `designate`/`designate-bind`/`designate-mysql-router`/ + `designate-hacluster` and `cinder-backup`/`ceph-rbd-mirror` are now IN the + same `bundle.yaml` this phase deploys -- the counts and "NO designate" GATE + text below are updated to match. **Genuinely unresolved, flagged rather + than decided:** this is the SAME shared bundle file used for both a plain + VR0/DC0 single-DC rehearsal redeploy and for standing up VR1's DC1 (per + the buildout design's own framing, VR0's testcloud IS becoming DC1, not + staying a separate thing) -- so ANY phase-01 run from this point forward + gets these new charms, whether the intent is a VR0-only continuation or a + DC-DC DC1 build. If a future session needs a plain VR0-only redeploy + WITHOUT Designate/cinder-backup/ceph-rbd-mirror, that needs an explicit + decision (a bundle fragment/override removing them for that one run) -- + do not assume either interpretation silently. --- @@ -36,7 +52,10 @@ (D-052/D-053). Resolve MAAS subnets BY CIDR (PATTERN-1), never by numeric subnet id -- ids drift across MAAS lifecycles. (DOCFIX-068 removed a stale pre-D-052 literal map that sat here.) -- expected plan: 50 apps, 97 relations, 4 machines (bundle 8/9/10/11 -> juju 0/1/2/3), 24 LXD. +- expected plan (as of `bundle.yaml` post-DOCFIX-167, 2026-07-10): 56 apps, + 108 relations, 4 machines (bundle 8/9/10/11 -> juju 0/1/2/3), 24 LXD. (Was + 50 apps/97 relations before the Designate + cinder-backup + ceph-rbd-mirror + reactivation -- see the callout above.) ## Run-location legend - `# RUN: jumphost` -- `juju` + `maas admin` (MAAS profile is `admin`; never `maas list` -- DOCFIX-016). @@ -130,12 +149,16 @@ fi } ) ``` -**GATE:** (from the plan): 50 apps, 97 relations, 4 machines (8/9/10/11 -> 0/1/2/3), 24 LXD; +**GATE:** (from the plan): 56 apps, 108 relations, 4 machines (8/9/10/11 -> 0/1/2/3), 24 LXD; ceph-osd/0-3 one per node; nova-compute/0-2 on machines 1/2/3 ONLY (machine 0 = OSD+LXD host, no compute); channels match the matrix; relations include `octavia:certificates - vault:certificates`, `vault:shared-db - vault-mysql-router`, -`mysql-innodb-cluster:certificates - vault:certificates`; NO `vault:ha`, NO designate -(D-019). Only the two benign R11 warnings (L34 `name`, L55 `variables`). +`mysql-innodb-cluster:certificates - vault:certificates`; NO `vault:ha` (still +absent, unchanged); designate/designate-bind/designate-mysql-router/designate- +hacluster and cinder-backup/ceph-rbd-mirror NOW PRESENT (D-106/D-108, +2026-07-10 -- corrects this GATE's old "NO designate (D-019)" text, since +D-019 is superseded). Only the two benign R11 warnings (L34 `name`, L55 +`variables`). ## Step 1.3 -- Deploy (VIP-guarded) Re-run the VIP guard inline (the dry-run never echoes vip values), @@ -189,6 +212,15 @@ * Waiting on vault certs (expected pre-init): ovn-central x3, ovn-chassis x3 (incl nova-compute subordinates), ovn-chassis-octavia, neutron-api-plugin-ovn, barbican-vault. * octavia BLOCKED "Awaiting configure-resources" (D-021); gss unknown (pre-run). + * **NOT YET OBSERVED LIVE (2026-07-10, D-106/D-108 reactivation) -- add to this + checklist once a real deploy confirms it:** `designate` and `designate-bind` + have a `certificates: metal-internal` relation to vault (per `bundle.yaml`), + so BY THE SAME PATTERN as the apps above they are LIKELY also waiting on + vault certs pre-init -- inferred from the relation graph, not confirmed + against a real deploy. `cinder-backup` (subordinate) and `ceph-rbd-mirror` + have no certificates relation, so no equivalent expectation for them. If a + real deploy shows anything different for designate/designate-bind, correct + this list rather than trusting this inference. * magnum/0 BLOCKED "Ports which should be open, but are not: 9501" -- pre-vault posture: magnum-api is loopback-bound ([api] host not yet templated) and haproxy backends target unit IPs. EXPECTED phase-01 end-state; self-resolves at the phase-02 cert rollout (apache2