|
R6 RULED: close the two VIP gaps, then apply the HA overlay whole (D-121 note)
GA-R5: question and exact utterance quoted, dated, pushed before dependent work. Operator utterance: "Close the two VIP gaps first, then apply the overlay whole (Recommended)". THE TENSION IT RESOLVES. D-121 is titled "VR1 makes HA real -- scale the decorative single-unit control plane to 3". Deferring the overlay would have deployed VR1 in exactly the shape D-121 was written to retire. Applying it as-is would have shipped, for vault, precisely the defect D-121 exists to remove -- a pacemaker cluster with nothing to manage. Only the ruled sequence satisfies the decision rather than half of it. MEASURED BEFORE PRESENTING, and it reframed the question. The overlay scales 14 applications and moves all 12 base hacluster subordinates to cluster_count 3, but ELEVEN OF TWELVE principals already carry proper VIP triples. The gap is exactly two applications, and they are not the same shape: - designate is in the base bundle WITH an hacluster and an ha binding, no vip. - vault has NO hacluster in base at all and an EMPTY options block. The overlay INTRODUCES the vault-hacluster application, its cluster_count 3, and the vault:ha relation -- and still no vip. Vault is the deciding case because of blast radius: 23 relations consume vault:certificates, plus barbican-vault:secrets-storage. With no VIP every consumer binds a unit address and there is nothing for a failover to move. Remediating that on a live 3-unit vault means re-pointing 23 certificate relations and re-issuing SANs on a running cloud, which is why the faster option was refused. SEQUENCING CONSEQUENCE: R11 becomes a HARD Stage-5 precondition ordered BEFORE the overlay, not a parallel item. Scope is tractable and the pattern is already in-repo: octavia carries a correct triple (10.12.4.57 10.12.8.57 10.12.12.57), so R11 has a shape to copy rather than design. NOT resolved here, tracked separately: the Stage-6 radosgw multisite path is single-unit-shaped while this scales ceph-radosgw to 3; and provider-bundle-check.py checks cluster_count NOWHERE, which is precisely why decorative HA was found by an audit instead of by a gate. Address demand is not an argument against this -- R4's band ruling already covers the overlay's growth from 27 to ~55 LXD units. Execution is a separate gated step, not authorised by this ruling. Revert: git revert this commit; the ruling note is additive. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf |
|---|
|
|
| docs/CURRENT-STATE.md |
|---|
| docs/audit/queued-rulings-20260727.md |
|---|
| docs/design-decisions.md |
|---|