# Changelog 2026-07-09 -- Office1-local network + Office1 OPNsense edge ownership (DOCFIX-163) No live infrastructure touched -- OpenTofu module/wiring additions, runbook updates, and documentation only (prep-only session; no `tofu` binary available, same UNVALIDATED status as every other OpenTofu module in this repo). Closes tooling gap register items #12 and #16 in `docs/dc-dc-deployment-workflow.md`; surfaces a new item, #17, found while closing #16. ## Items ### 1. DOCFIX-163 -- `opentofu/modules/office1-network` (closes gap #12) FILES: `opentofu/modules/office1-network/main.tf`, `opentofu/modules/office1-network/variables.tf`, `opentofu/modules/office1-network/outputs.tf`, `opentofu/main.tf` (new `module "office1_network"` block, instantiated for real), `opentofu/README.md`. WHAT: a new module, shaped exactly like `modules/dc-planes` (isolated `libvirt_network`, no `forward`/DHCP block, attribute-style nested-object syntax per this provider's confirmed schema convention) but sized for ONE network instead of six planes -- Office1 is a headend, not a per-DC OpenStack cloud, so the six-plane D-052/D-100 template does not apply to it. This is the 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 all attach to -- previously modeled nowhere in `opentofu/` (gap #12, found 2026-07-09 while drafting `runbooks/dc-dc-phase1-office1-standup.md`). DESIGN DECISION: a NEW module, not a reused host bridge (the runbook's own "Open questions" section had left this as a genuine, undecided fork). Reasoning, in full in the module's own header comment and in `runbooks/dc-dc-phase1-office1-standup.md`'s Open question #1: - D-103 already establishes that OpenTofu owns create/destroy of every virtual network in this topology. A hand-configured host bridge would be the one network 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 (as a DOCFIX candidate) whenever Option B (manual VM creation) is used elsewhere in the same runbook. - This repo's own CHECK steps (`virsh net-list --all`, used throughout the Stage 1/2 runbooks) implicitly assume that command is a COMPLETE inventory of what exists on vcloud. A pre-existing, OpenTofu-invisible bridge would silently break that assumption, and Stage 0's teardown path (D-061) would never reach it. Instantiated for REAL in root `main.tf` (`module "office1_network"`), unlike most of the other still-scaffolded modules in this repo -- it needs no unmeasured value beyond `domain_suffix`/`underlay_mtu`, both already real, already-required inputs elsewhere in the same file (the identical reasoning that already lets the three `mesh-link` legs be instantiated today). VERIFIED: - `bash scripts/repo-lint.sh`: 0 fail, 1 documented legacy WARN (unchanged). - **UNVALIDATED against a real provider** -- no `tofu` binary was available this session (same status as every other module in `opentofu/`; see `opentofu/README.md`'s top-level status line). Run `bash scripts/opentofu-validate.sh` on a connected machine before trusting the schema. REVERT: `git checkout HEAD~ -- opentofu/main.tf opentofu/README.md && rm -rf opentofu/modules/office1-network` (safe -- nothing else references this module yet). ### 2. DOCFIX-163 -- Office1 OPNsense edge ownership decision (closes gap #16) FILES: `opentofu/main.tf` (new, commented-out `module "office1_opnsense"` skeleton), `opentofu/README.md`, `runbooks/dc-dc-phase1-office1-standup.md` (new Step 4b, updated Open questions/Sequence/GATE/delivery-checklist sections). WHAT: the buildout design's topology (Section 1) is explicit -- "full dark-fiber triangle... plus a **per-site** OPNsense simulated ISP edge," three sites, three edges. Stage 3's Build list already covered DC1/DC2's edges (`modules/opnsense-edge` per DC); neither Stage 2's nor Stage 3's runbook instantiated one for Office1 (gap #16, found 2026-07-09 during final consolidation of the DC-DC runbook set). DECISION: **YES, Office1 gets its own `modules/opnsense-edge` call, a fourth site alongside DC1/DC2 -- and Stage 2's own runbook (`runbooks/dc-dc-phase1-office1-standup.md`) owns creating it**, via a new Step 4b (CHECK-before-MUTATION shape, its own GATE bullet, matching the runbook's existing style exactly). Rationale: Stage 2's entire scope is already "Office1 headend standup" -- the OPNsense edge is part of that headend's own boundary, not DC substrate -- and Stage 1 already creates the mesh-link networks this edge's neighbors depend on; Stage 3 has no reason to reach back into Office1's own infrastructure to build a piece of it. The new `module "office1_opnsense"` skeleton in `main.tf` mirrors Stage 3's `dc1_opnsense` template shape exactly (same module, same variable names). Its `lan_network_name` resolves cleanly to Item 1's new network (`module.office1_network.network_name`). Its `wan_network_name` does NOT -- see Item 3 below. The block stays commented out, same as DC1/DC2's own not-yet-instantiated edges (neither is real either, per `opentofu/README.md`), pending real `memory_mib`/`vcpu`/`disk_size_bytes`/ `base_volume_path`/`config_iso_path` values plus gap #17's resolution. VERIFIED: `bash scripts/repo-lint.sh`: 0 fail (module block is commented out; nothing new to `tofu validate` here that Item 1 didn't already cover). REVERT: `git checkout HEAD~ -- opentofu/main.tf opentofu/README.md runbooks/dc-dc-phase1-office1-standup.md` (safe -- Step 4b's module call was never uncommented/applied). ### 3. Gap register item #17 (NEW) -- no per-site ISP-uplink/WAN network exists yet, for any site Investigated per this task's own instruction to check before inventing a WAN-side network for Office1's edge: read `runbooks/dc-dc-phase2-tofu-dc-substrate.md` Step 5 directly. Its own `dc1_opnsense` template carries an IDENTICAL, still-unresolved placeholder: ``` wan_network_name = module.mesh_dc1_office1... # or a dedicated per-site ISP-uplink segment -- confirm which, do not assume ``` This confirms the WAN-side network question is NOT Office1-specific -- it is a genuinely deeper, cross-site gap that also blocks DC1's and DC2's own edges, not something this delivery could resolve alone without inventing a value or (worse) defaulting Office1's WAN side to a mesh-link network, which would directly contradict D-100's own sub-item ruling that the three dark-fiber mesh legs carry MANAGEMENT TRAFFIC ONLY (Office1<->DC = MAAS/ Juju/operator), not a simulated ISP uplink. Logged as new tooling gap register item #17 in `docs/dc-dc-deployment-workflow.md`, cross-referenced from gaps #4/#12/#16 and from both new module headers -- flagged rather than invented, per this task's own instruction. ## Next actionable step Tooling gap register items #12 and #16 CLOSED. Gap #17 (NEW) is now the blocking dependency for instantiating ANY of the three sites' `opnsense-edge` calls end-to-end -- needs a decision on the WAN-side network shape (most likely a fourth per-site `libvirt_network`, analogous to `office1-network`/`mesh-link`/`dc-planes`) before `dc1_opnsense`, `dc2_opnsense`, or `office1_opnsense` can be uncommented for real. Designing the three Office1 service VMs' actual `cloudinit-vm` `network_config` content against the now-real `office1-local` network remains separate, un-actioned work (unchanged by this delivery).