# office1-network: Office1's own LOCAL virtual network (closes tooling gap
# register item #12 in docs/dc-dc-deployment-workflow.md) -- the single
# shared L2 segment the three Office1 service VMs (MAAS-region, NetBox,
# GitBucket), the vcloud host's own management interface, and Office1's own
# OPNsense edge's LAN side (gap #16) all attach to.
#
# DESIGN DECISION (2026-07-09, resolves gap #12's own "new module vs. host-
# bridge reuse" fork): a NEW dc-planes-shaped module, NOT a reused host
# bridge. Reasoning:
#   1. `modules/dc-planes`, `modules/mesh-link`, and `modules/dc-storage-pool`
#      already establish the precedent that every virtual network/pool this
#      repo depends on is a versioned, destroy/recreate-safe OpenTofu
#      resource -- per D-103 ("OpenTofu owns create/destroy of ... all
#      virtual networks"). A hand-configured host bridge would be the ONE
#      network in this whole topology living outside that inventory --
#      exactly the "not reproducible / not versioned" debt D-103 exists to
#      eliminate, and the same class of debt this repo already logs
#      explicitly when Option B (manual VM creation) is used elsewhere (see
#      runbooks/dc-dc-phase1-office1-standup.md's "Provisioning-path
#      decision" section).
#   2. This repo's own audit/CHECK steps assume `virsh net-list --all` is a
#      COMPLETE inventory of what exists on vcloud (see
#      runbooks/dc-dc-phase1-office1-standup.md's Stage-1-gate CHECK). A
#      pre-existing host bridge, created outside OpenTofu, would silently
#      break that assumption -- a real bridge would exist that no `tofu
#      plan`/`tofu destroy` knows about, and Stage 0's teardown path
#      (D-061) would not reach it.
#   3. Shaped like `modules/dc-planes` but for ONE network, not six planes:
#      Office1 is a headend, not an OpenStack DC, so the D-052/D-100
#      six-plane template does not apply to it -- it needs exactly one
#      shared local segment, not a plane family.
#
# Isolated, not NAT/routed -- same reasoning as dc-planes/mesh-link: no
# libvirt-managed DHCP (NetBox is the IPAM apex, skill hard rule 3);
# `forward` is OMITTED entirely, which is documented native-libvirt behavior
# for a private, unforwarded virtual switch (this repo could not confirm the
# provider's `forward.mode` accepted string values from the published docs --
# see dc-planes/main.tf's identical, still-open caveat). Confirm with `tofu
# providers schema -json` before the first real apply; add `mode = "none"`
# then if it turns out to still be required -- do not guess it in now.
#
# SYNTAX NOTE: this provider's current schema uses attribute-style nested
# objects (`domain = { ... }`, `mtu = { ... }`), not classic HCL nested
# blocks -- the same provider-wide convention confirmed against real example
# .tf files and documented in opentofu/README.md's "Syntax bug fixed
# 2026-07-09" section (dc-planes/mesh-link/dc-storage-pool all originally
# shipped with the wrong, block-style syntax and were corrected). This
# module is written directly in the corrected style from the start.

resource "libvirt_network" "office1_local" {
  name      = "office1-local"
  autostart = true

  domain = {
    name = "office1.${var.domain_suffix}"
  }

  mtu = {
    size = var.mtu
  }
}