# overlays/vr1-dc0-machines.yaml
#
# The vr1-dc0 half of the hand-maintained per-DC overlay pair. Created 2026-07-29
# (item 3.8). Its sibling is overlays/vr1-dc1-machines.yaml.
#
# WHY THIS FILE EXISTS AT ALL, given that bundle.yaml's `machines:` block already
# carries dc0's tags: `overlays/${DC}-machines.yaml` is a path that TWO consumers
# already name -- scripts/preflight.sh's P2 overlay assembly and
# runbooks/dc-dc-phase6-designate-cos-magnum.md. Both guard it with `[ -f ]` or the
# equivalent, so while the dc0 file did not exist they SILENTLY SKIPPED it: P2 went
# green having validated a different input than the deploy would use. Creating the
# file closes that hole from the artifact side rather than by adding another guard.
#
# THIS OVERLAY IS `applications:`-ONLY -- IT RETAGS NOTHING.
# bundle.yaml's machines block is the vr1-dc0 source of truth and already reads
# `tags=openstack-vr1-dc0,<role>` for ids 0-8, so dc0 needs no machines-block delta;
# only dc1 does (that is what its sibling overlay is for). Do not add a `machines:`
# block here to make the pair look symmetric -- it would duplicate the base values in
# a second place and create a drift surface for no gain. The filename is therefore
# slightly broader than "machines": it is the per-DC HAND-MAINTAINED overlay. Renaming
# it would require editing scripts/preflight.sh, which this file does not own.
#
# ---- ovn-chassis bridge-interface-mappings: WHY IT LIVES HERE ----
# MOVED OUT OF bundle.yaml 2026-07-29 (item 3.8). The base bundle carried vr1-DC1's
# MACs while being documented as dc0's source of truth, so a dc0 deploy matched no
# local MAC, ovn-chassis built no br-ex mapping, provider egress was dead on dc0
# compute, and no gate failed (provider-bundle-check only COUNTS well-formed MACs; it
# never checks the prefix, and `if not bim: continue` makes ABSENCE a silent skip).
# Governing text: the D-124 coupling entry's 2026-07-27 correction in
# docs/design-decisions.md -- "ovn-chassis bridge-interface-mappings is a PER-DC value
# and must become renderer OUTPUT into the per-DC overlay ... It must also move OUT of
# the base bundle for the 2026-07-25 symmetric-overlay ruling to be truthful."
# It is placed in the MACHINES overlay, not the vips overlay, because
# overlays/vr1-dc0-vips.yaml is GENERATED by scripts/render-dc-overlays.py and says
# "do not hand-edit" -- a key added there is clobbered on the next render. When the
# renderer is extended to emit this value (the "renderer OUTPUT" half of the same
# correction), it should emit INTO this file, not into the vips file.
#
# ---- THE MAC VALUES: MEASURED, AND NOT WHERE TWO REPO RECORDS SAY THEY ARE ----
# vr1-dc0's MACs are NON-schematic (measured 52:54:00:* values), unlike dc1's derivable
# 52:54:01:d1:NN:PP scheme, so every one of them has to be read from a capture.
#
# SOURCE OF TRUTH: opentofu/vr1-dc0-substrate/main.tf, the `vr1_dc0_nodes` map. Its
# own comment fixes the ordering: "Order = vr1_dc0_node_nics order (metal-admin,
# provider-public, metal-internal, data-tenant, storage, replication)" -- metal-admin
# FIRST (:77 "metal-admin FIRST = PXE/boot plane"). So the provider-public MAC is
# element [1], the SECOND entry, never the first:
#   vr1-dc0-compute-01 (main.tf:109-112) -> [0] 52:54:00:1b:19:e6 metal-admin/PXE
#                                           [1] 52:54:00:8c:2a:8c provider-public  <-- used
#   vr1-dc0-compute-02 (main.tf:113-116) -> [0] 52:54:00:18:ab:b4 metal-admin/PXE
#                                           [1] 52:54:00:50:48:88 provider-public  <-- used
#
# CROSS-CHECKED against two independent captures:
#   docs/audit/inner-plan-20260721-macpin.txt:36-72 / :85-123 -- the tofu plan that
#     pinned them, listing each domain's interfaces in vr1_dc0_node_nics order.
#   docs/audit/stage5-committee-raw-20260727.md:323 -- live MAAS, 18/18 nodes:
#     "`enp1s0..enp6s0` + `br-ex`. `enp2s0` correctly carries no link (D-100
#     provider-raw); `br-ex` is a bridge over `enp2s0`". NIC position 2 = provider-
#     public = the br-ex member. This is the same positional slot dc1 encodes as `:02`.
#
# !! TWO REPO RECORDS ARE WRONG ABOUT THIS AND WILL MISLEAD THE NEXT READER !!
#   - docs/audit/stage5-unmeasured-register-20260727.md, row U5, states dc0's
#     "compute provider-public MACs" are 52:54:00:1b:19:e6 / 52:54:00:18:ab:b4 and
#     notes they match scripts/lib-hosts.sh:121-122. They DO match lib-hosts -- but
#     lib-hosts.sh:121-122 is HOST_BOOT_MAC, the metal-admin/PXE NIC ([0]), NOT
#     provider-public. U5 labels the boot MACs as provider MACs.
#   - the D-124 coupling correction says this value should be "sourced from
#     lib-hosts.sh". lib-hosts.sh carries ONLY HOST_BOOT_MAC and therefore CANNOT
#     source it; the substrate main.tf is the only in-repo source for NIC [1].
# Taking either record at face value would have put the PXE MAC in br-ex -- br-ex
# bridged onto the boot/metal-admin NIC instead of the provider NIC. Both are logged
# as findings; neither file is edited here.
#
# The charm picks whichever MAC is local per unit and ignores non-matching entries;
# 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.
#
# VERIFY-LIVE (this file is a NEW merge surface -- assert it at `juju deploy --dry-run`
# BEFORE any deploy; no offline juju merger exists to prove it here). The dry-run must
# show base `ovn-chassis` keeping 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
# file exists to fix. 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.
#
# Applied as part of the vr1-dc0 per-DC set (R6: this set lands BEFORE
# overlays/dc-ha-scaleup.yaml, never in the same command as it):
#   juju deploy ./bundle.yaml \
#     --overlay overlays/vr1-dc0-vips.yaml \
#     --overlay overlays/vr1-dc0-machines.yaml \
#     --overlay overlays/vr1-dc0-octavia-pki.yaml \
#     -m "${DC_MODEL}"
applications:
  ovn-chassis:
    options:
      bridge-interface-mappings: >-
        br-ex:52:54:00:8c:2a:8c
        br-ex:52:54:00:50:48:88