# overlays/vr1-dc1-machines.yaml
#
# Retag the 9-machine block from the vr1-dc0 base to vr1-dc1 for the dc1 deploy.
# ONE Office1 MAAS region sees BOTH DCs' nodes (D-104/D-123 single region), so the
# machines-block constraint must carry the DC-scoping tag or dc1's model could grab a
# dc0 node. The DC tag (openstack-vr1-dc1) selects THIS DC's nodes; the role sub-tag
# (control/compute/storage, applied at Stage 4 per Fork-3) selects the role. The base
# bundle.yaml is the vr1-dc0 source of truth (matches overlays/vr1-dc1-vips.yaml);
# this overlay + the VIP overlay are the two per-DC deltas for dc1.
#
# Applied as the vr1-dc1 per-DC set:
#   juju deploy ./bundle.yaml \
#     --overlay overlays/vr1-dc1-vips.yaml \
#     --overlay overlays/vr1-dc1-machines.yaml \
#     --overlay overlays/vr1-dc1-octavia-pki.yaml \
#     -m "${DC_MODEL}"
#
# CORRECTED 2026-07-29 (NEW-7), two defects in the command above:
#   1. It listed `--overlay overlays/dc-ha-scaleup.yaml` in the SAME deploy command as
#      the VIP overlay. R6 (RULED 2026-07-27, docs/design-decisions.md) forbids that
#      ordering: operator utterance "Close the two VIP gaps first, then apply the
#      overlay whole". The two VIP gaps are vault and designate; R11 landed their VIPs
#      in the per-DC vips overlays (.61 / .62). In ONE command the two overlays merge
#      before anything deploys, so the scale-up and the VIPs arrive together and the
#      "VIPs first" sequence R6 ruled cannot be observed at all. dc-ha-scaleup.yaml is
#      applied SEPARATELY, AFTER this set is deployed and settled -- see that file's
#      own header. Do not re-merge them.
#   2. It used a THIRD model-variable spelling, `${DC1_MODEL}`. The runbooks use
#      `${DC_MODEL}` (the per-DC model of whichever DC is being deployed); this overlay
#      is already dc1-scoped by its filename, so the variable must not be too.
#
# VERIFY-LIVE: confirm the machines-block override merges as expected at
# `juju deploy --dry-run` BEFORE deploy (no offline juju merger exists to prove it
# here). If it does not take, the fallback is inlining these dc1 tags into a rendered
# dc1 bundle (cheap) -- see committee-20260724-track2-bundle-render.md, Fork 2.
#
# VERIFY-LIVE, SECOND ASSERTION (added 2026-07-29 with the ovn-chassis block below --
# this file is no longer machines-only, so the old note no longer covers everything it
# changes). The dry-run must ALSO show that base `ovn-chassis` keeps BOTH of its
# existing options alongside the new one:
#     ovn-bridge-mappings: physnet1:br-ex
#     prefer-chassis-as-gw: true        (B2 -- gateway-chassis election)
# This overlay sets only `bridge-interface-mappings` under `options`. That is safe IF
# juju merges the `options` MAP key-by-key, and unsafe if it REPLACES the map -- in
# which case the physnet mapping and the B2 gateway election both vanish from the
# deploy input and provider egress dies, by a different route than the defect this
# move fixed. Key-by-key is near-certain (the whole *-vips.yaml architecture depends
# on it -- those overlays set `options.vip` on apps carrying other base options) but
# it is NOT PROVEN HERE: provider-bundle-check.py's `_deep_merge` merges key-by-key
# by construction, so validating through the checker cannot tell the two behaviours
# apart. Only the live dry-run can. Assert it explicitly; do not assume.
#
# ---- ovn-chassis bridge-interface-mappings: MOVED HERE FROM bundle.yaml 2026-07-29 ----
# These exact two values previously sat in the BASE bundle (item 3.8), which is
# documented as vr1-DC0's source of truth -- a residue of the 2026-07-24 dc1-first
# render. They are unchanged in value, only relocated to the DC they actually describe.
# The defect they caused was on the OTHER side: a dc0 deploy matched no local MAC,
# ovn-chassis built no br-ex mapping, and provider egress was dead on dc0 compute with
# no gate failing. Governing text: the D-124 coupling entry's 2026-07-27 correction in
# docs/design-decisions.md -- bridge-interface-mappings "is a PER-DC value and must
# become renderer OUTPUT into the per-DC overlay ... must also move OUT of the base
# bundle for the 2026-07-25 symmetric-overlay ruling to be truthful".
#
# VALUES RE-MEASURED, not copied on trust: opentofu/vr1-dc1-substrate/main.tf:112-119.
# The scheme is 52:54:01:d1:NN:PP where "PP = NIC ordinal 01..06 in vr1_dc1_node_nics
# order (metal-admin first)" (:95-98), so provider-public is PP=02, the SECOND NIC --
# NOT :01, which is the metal-admin/PXE boot MAC in lib-hosts.sh HOST_BOOT_MAC.
#   vr1-dc1-compute-01 -> NN=04 -> 52:54:01:d1:04:02
#   vr1-dc1-compute-02 -> NN=05 -> 52:54:01:d1:05:02
# Cross-checked live: docs/audit/stage5-committee-raw-20260727.md:323 records 18/18
# nodes as `enp1s0..enp6s0` + `br-ex`, with `br-ex` a bridge over `enp2s0` (position 2
# = provider-public, D-100 provider-raw). Same positional slot as dc0's measured pair.
# The charm ignores non-local MACs; ovn-chassis is subordinate to the 2-unit
# nova-compute, so exactly these two compute hosts carry br-ex. Exactly 2 MACs belong
# here -- a third means a wrong node. See overlays/vr1-dc0-machines.yaml for dc0's set
# and for the two repo records that mislabel the PXE MACs as the provider MACs.
applications:
  ovn-chassis:
    options:
      bridge-interface-mappings: >-
        br-ex:52:54:01:d1:04:02
        br-ex:52:54:01:d1:05:02

machines:
  "0":
    constraints: arch=amd64 tags=openstack-vr1-dc1,control
  "1":
    constraints: arch=amd64 tags=openstack-vr1-dc1,control
  "2":
    constraints: arch=amd64 tags=openstack-vr1-dc1,control
  "3":
    constraints: arch=amd64 tags=openstack-vr1-dc1,compute
  "4":
    constraints: arch=amd64 tags=openstack-vr1-dc1,compute
  "5":
    constraints: arch=amd64 tags=openstack-vr1-dc1,storage
  "6":
    constraints: arch=amd64 tags=openstack-vr1-dc1,storage
  "7":
    constraints: arch=amd64 tags=openstack-vr1-dc1,storage
  "8":
    constraints: arch=amd64 tags=openstack-vr1-dc1,storage