# overlays/dc-ha-scaleup.yaml # # D-121 (ADOPTED IN PART, 2026-07-15) VR1 HA scale-up overlay -- makes the # decorative single-unit control plane REAL by scaling 14 services from # num_units: 1 to 3. VR1-SPECIFIC: VR0/testcloud stays single-unit BY DESIGN # (D-009), so this is an overlay, NOT a bundle.yaml edit -- same pattern as # overlays/dc-dc-ipv6-family-matrix.yaml. Apply ALONGSIDE bundle.yaml's other # overlays, e.g.: # juju deploy ./bundle.yaml \ # --overlay overlays/octavia-pki.yaml \ # --overlay "overlays/${DC}-hostnames.yaml" \ # --overlay overlays/dc-ha-scaleup.yaml \ # -m "${DC_MODEL}" # # NOT YET APPLIED to any live model -- authored prep-only (STAGE 5 prep; the # per-DC bundle deploy is two stages out). No live cloud reached this session. # # ===================================================================== # ##### STAGE-4 BINDING REQUIRED -- READ BEFORE RENDER ##### # Every `to:` target below is a {{TOKEN}} placeholder for one of the three # Option C control nodes (vr1-dc0-control-01..03, D-121). The REAL Juju machine # IDs do NOT exist yet -- they bind at Stage 4, AFTER MAAS enlists the Option C # node VMs. Do NOT invent concrete `lxd:N` numbers here: a wrong number # silently mis-places a unit and defeats the anti-affinity that is the entire # HA value. Render this file (substitute the three tokens with the measured, # enlisted control-node machine IDs) ONLY at Stage 4/5, exactly as # dc-dc-ipv6-family-matrix.yaml's VIP tokens are rendered. The rendered # bundle.yaml `machines:` block MUST define those same three IDs. # {{VR1_DC0_CONTROL_01}} -> control node 1 machine id # {{VR1_DC0_CONTROL_02}} -> control node 2 machine id # {{VR1_DC0_CONTROL_03}} -> control node 3 machine id # ===================================================================== # # PLACEMENT / ANTI-AFFINITY (D-121 balance rule). Juju bundles have NO dedicated # anti-affinity primitive; one-per-node is expressed POSITIONALLY -- a 3-entry # `to:` list binds unit0->entry0, unit1->entry1, unit2->entry2. Every scaled app # below uses the SAME three-control-node spread, so: # - each app lands exactly one unit per control node (14 apps x 1 = ~14 API # LXD containers per control node -- the even ~14/node density the 64 GiB # control-node sizing was validated for, D-121); and # - the RAM-heavy stateful trio (mysql-innodb-cluster already 3 in the base # bundle, rabbitmq-server + vault scaled here) auto-balances to one replica # per control node -- never two stacked on one node. # # THREE ITEMS BELOW GO BEYOND A LITERAL `num_units: 3` BUMP. They are NOT # scope-creep: each is the same class of "mechanical 1->3 hides a gotcha" that # D-121 itself flags (D-121 caught the placement rewrite; these are the two it # under-states plus the one its own wording got wrong), and an overlay titled # "make HA real" that shipped decorative HA would not meet its stated purpose. # All three are called out in the delivery changelog, not slipped in: # (A) rabbitmq-server min-cluster-size: 3. Per D-009 AMENDMENT (2026-07-02): # "rabbitmq scale-up is NOT mechanical without min-cluster-size" -- without # it the charm accepts client relations BEFORE the cluster forms (same race # as the D-062 mysql formation failure). Roosevelt/VR1 delta = set it # alongside num_units: 3. rabbitmq clusters natively (quorum), NO hacluster. # (B) hacluster cluster_count: 3 (all 12 active hacluster subs + the re-added # vault-hacluster). The base bundle pins cluster_count: 1 -- explicitly # "decorative on single-unit testcloud" (D-009 / BUNDLEFIX-003). At 3 units # with cluster_count still 1, pacemaker can bootstrap the VIP off a single # node = the SAME decorative behavior D-121 exists to eliminate. 3 makes # the charm wait for a real 3-node quorum before configuring resources. # VERIFY at deploy (not fetched this session): confirm the hacluster # 2.4/stable charm treats cluster_count as "peers required before the # cluster forms / VIP binds" -- the base bundle explicitly pinned it to 1 # as decorative, and real 3-node quorum needs 3 regardless of the charm # default. Flag if `juju config hacluster` disagrees. # (C) vault-hacluster is DEFINED here, not just related. D-121's prose says it # "exists among the hacluster subs" -- it does NOT: bundle.yaml line ~923 # has it COMMENTED OUT (removed by BUNDLEFIX-002 when vault was de-HA'd, # C1). So the re-added `[vault:ha, vault-hacluster:ha]` relation would # reference a non-existent app (provider-bundle-check rule 4 would FAIL). # This overlay re-declares it, matching the other haclusters' shape. # # VAULT BACKEND (D-121 sub-ruling = v-a, RESOLVED 2026-07-15): vault stays # MYSQL-backed (on the already-3-unit mysql-innodb-cluster via vault-mysql-router, # unchanged) and scales to 3 -- NO etcd, NO Raft here. GATE (Stage 5, before # commit): verify the deployed vault 1.8/stable charm actually does HA # leader-election on the MySQL storage backend at 3 units. If it does NOT: do # NOT fall back to etcd -- evaluate Raft integrated storage and route to D-068. # 3-unit vault ALSO triples the manual-unseal burden (intersects OPEN SEC-003). # # NOT changed here (deliberately, per D-121): mysql-innodb-cluster / ovn-central # / ceph-mon (already 3 in the base bundle); ceph-osd / nova-compute (scale-out, # sized to node count -- Option C = ceph-osd 3, nova-compute 2, on the storage / # compute nodes, NOT control-node containers); ceph-rbd-mirror stays 1 (D-108); # memcached / designate-bind / glance-simplestreams-sync unchanged. # ===================================================================== applications: # ---- Clustered API charms (hacluster + dual VIP already wired in base) ---- # Each: 1 -> 3 units, one per control node (positional anti-affinity). keystone: num_units: 3 to: ["lxd:{{VR1_DC0_CONTROL_01}}", "lxd:{{VR1_DC0_CONTROL_02}}", "lxd:{{VR1_DC0_CONTROL_03}}"] glance: num_units: 3 to: ["lxd:{{VR1_DC0_CONTROL_01}}", "lxd:{{VR1_DC0_CONTROL_02}}", "lxd:{{VR1_DC0_CONTROL_03}}"] neutron-api: num_units: 3 to: ["lxd:{{VR1_DC0_CONTROL_01}}", "lxd:{{VR1_DC0_CONTROL_02}}", "lxd:{{VR1_DC0_CONTROL_03}}"] nova-cloud-controller: num_units: 3 to: ["lxd:{{VR1_DC0_CONTROL_01}}", "lxd:{{VR1_DC0_CONTROL_02}}", "lxd:{{VR1_DC0_CONTROL_03}}"] placement: num_units: 3 to: ["lxd:{{VR1_DC0_CONTROL_01}}", "lxd:{{VR1_DC0_CONTROL_02}}", "lxd:{{VR1_DC0_CONTROL_03}}"] cinder: num_units: 3 to: ["lxd:{{VR1_DC0_CONTROL_01}}", "lxd:{{VR1_DC0_CONTROL_02}}", "lxd:{{VR1_DC0_CONTROL_03}}"] openstack-dashboard: num_units: 3 to: ["lxd:{{VR1_DC0_CONTROL_01}}", "lxd:{{VR1_DC0_CONTROL_02}}", "lxd:{{VR1_DC0_CONTROL_03}}"] octavia: num_units: 3 to: ["lxd:{{VR1_DC0_CONTROL_01}}", "lxd:{{VR1_DC0_CONTROL_02}}", "lxd:{{VR1_DC0_CONTROL_03}}"] barbican: num_units: 3 to: ["lxd:{{VR1_DC0_CONTROL_01}}", "lxd:{{VR1_DC0_CONTROL_02}}", "lxd:{{VR1_DC0_CONTROL_03}}"] magnum: num_units: 3 to: ["lxd:{{VR1_DC0_CONTROL_01}}", "lxd:{{VR1_DC0_CONTROL_02}}", "lxd:{{VR1_DC0_CONTROL_03}}"] designate: num_units: 3 to: ["lxd:{{VR1_DC0_CONTROL_01}}", "lxd:{{VR1_DC0_CONTROL_02}}", "lxd:{{VR1_DC0_CONTROL_03}}"] ceph-radosgw: num_units: 3 to: ["lxd:{{VR1_DC0_CONTROL_01}}", "lxd:{{VR1_DC0_CONTROL_02}}", "lxd:{{VR1_DC0_CONTROL_03}}"] # ---- RabbitMQ: native quorum clustering, NO hacluster. min-cluster-size is # MANDATORY at multi-unit (D-009 AMENDMENT 2026-07-02, item A above). ---- rabbitmq-server: num_units: 3 options: min-cluster-size: 3 to: ["lxd:{{VR1_DC0_CONTROL_01}}", "lxd:{{VR1_DC0_CONTROL_02}}", "lxd:{{VR1_DC0_CONTROL_03}}"] # ---- Vault: MySQL-backed (v-a), scale to 3, re-HA'd via vault-hacluster # (defined below) + the relation re-added at the foot of this file. ---- vault: num_units: 3 to: ["lxd:{{VR1_DC0_CONTROL_01}}", "lxd:{{VR1_DC0_CONTROL_02}}", "lxd:{{VR1_DC0_CONTROL_03}}"] # ---- vault-hacluster: RE-DECLARED (item C above). Removed by BUNDLEFIX-002 # when vault was de-HA'd; D-121 (v-a) brings it back. Shape matches the # other hacluster subs in bundle.yaml, with cluster_count: 3 (real HA). ---- vault-hacluster: {charm: hacluster, channel: 2.4/stable, options: {cluster_count: 3}, bindings: {'': metal-admin, ha: metal-internal, hanode: metal-internal, pacemaker-remote: metal-internal, peer-availability: metal-internal}} # ---- cluster_count: 1 -> 3 for the 12 active hacluster subs (item B above). # Overlay apply deep-merges options per-key -- the SAME mechanism # dc-dc-ipv6-family-matrix.yaml already relies on (it supplies only # `options:` for keystone et al. and depends on charm/channel/bindings # surviving from base). So ONLY cluster_count is overridden here; each # sub's base bindings/charm/channel are preserved. ---- keystone-hacluster: {options: {cluster_count: 3}} glance-hacluster: {options: {cluster_count: 3}} neutron-api-hacluster: {options: {cluster_count: 3}} nova-cloud-controller-hacluster: {options: {cluster_count: 3}} placement-hacluster: {options: {cluster_count: 3}} openstack-dashboard-hacluster: {options: {cluster_count: 3}} cinder-hacluster: {options: {cluster_count: 3}} octavia-hacluster: {options: {cluster_count: 3}} barbican-hacluster: {options: {cluster_count: 3}} magnum-hacluster: {options: {cluster_count: 3}} ceph-radosgw-hacluster: {options: {cluster_count: 3}} designate-hacluster: {options: {cluster_count: 3}} relations: # ---- Re-add vault HA (removed by BUNDLEFIX-002; D-121 v-a re-adds it). # vault already carries the `ha: metal-internal` binding in the base # bundle, and vault-hacluster is declared above. ---- - [vault:ha, vault-hacluster:ha]