# wan-bridge: the DC WAN segment realized as a libvirt BRIDGE onto a pre-existing
# host bridge (D-125, Model B bridge-in). NOT a NAT and NOT a subnet owner --
# see variables.tf for why this exists (OBS-3) and how it differs from site-wan.
#
# SCHEMA NOTE: same provider (registry.opentofu.org/dmacvicar/libvirt) and same
# attribute-style nesting confirmed by modules/site-wan (via
# `tofu providers schema -json`):
#   forward = { mode = "bridge" }   (nesting=single; no top-level `mode`)
#   bridge  = { name = "<host bridge>" } (attribute-object; the existing Linux bridge)
#   mtu     = { size = N }          (nesting=single; matches site-wan/dc-planes)
# No `ips` and no NAT: addressing lives on the vcloud ISP /24 that the host
# bridge's enslaved uplink NIC reaches; the edge WAN is static there (D-113).

resource "libvirt_network" "wan_bridge" {
  name      = var.network_name
  autostart = true

  # forward mode = bridge: hand traffic straight onto an existing host bridge;
  # libvirt neither creates the bridge nor manages L3 on it (the bootstrap does).
  forward = {
    mode = "bridge"
  }

  bridge = {
    name = var.host_bridge
  }

  # NO mtu block: libvirt REJECTS <mtu> in forward mode "bridge" ("mtu size only
  # allowed in open, route, nat, and isolated mode" -- measured at the first real
  # apply, 2026-07-20; the schema parses it but define fails, DOCFIX-194 class).
  # Correct as well as necessary: on a bridge-mode network the MTU is a property
  # of the underlying host bridge (br-vr1-dc0-wan, 1500 via the outer netplan),
  # and guest interfaces inherit it from there.
}