Fork: 0
OpenStack / openstack-caracal-dc-dc
Transfer to URL with SHA Find file
Newer
Older
openstack-caracal-dc-dc / docs / changelog-20260710-phase01-bundle-staleness-fix.md
@JANeumatrix JANeumatrix 2 hours ago 3 KB DOCFIX-169: fix stale bundle.yaml expectations in phase-01-bundle-deploy.md
Raw Blame History

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