GitBucket
2026-07-13 -- the workflow doc's status was materially FALSE
docs/dc-dc-deployment-workflow.md is the first thing a fresh session reads. Its status claims were written 2026-07-09 and never updated, so they had drifted into being wrong in ways that would misdirect real work. Corrected against MEASURED state, not impressions. Docs only; no code, no live system touched.
What was false, and what is true
| claim in the doc | reality (measured 2026-07-13) |
|---|---|
gap #2: "UNVALIDATED -- no tofu binary available" |
OpenTofu v1.12.3 IS installed. The tree validates: root + 10/10 modules. It has also been APPLIED -- 11 resources in state. |
opentofu/ "SCAFFOLDED, UNVALIDATED" |
VALIDATED and partly APPLIED. But 2 modules were BROKEN and had never been parsed (DOCFIX-194) -- see below. |
| gap #17: "no per-site ISP-uplink network exists anywhere, for ANY site" | CLOSED FOR OFFICE1. office1-wan is live (virbr11, NAT, 172.30.1.0/24); the edge's WAN is on it at 172.30.1.2, egress verified. The gap's own proposed answer (a dedicated per-site uplink network, NOT a mesh leg) is what was built. DC1/DC2 still have none -- dc1-provider-public has no IP and no forward. |
modules/opnsense-edge "BUILT, UNVALIDATED (no real boot)" |
BUILT, INSTANTIATED, RUNNING. Routing, NAT, egress 0.0% loss, serial console, SSH-key managed, Kea DHCP on udp/67. |
templates/opnsense-config.xml.tmpl "BUILT, renderer fully tested" |
SUPERSEDED by D-113(a2) -- config is REST-API-managed. A full config.xml push would now CLOBBER live DHCP. |
modules/netem-link "BUILT, UNVALIDATED" |
WAS BROKEN (destroy provisioner referencing var.* -- could not even init). Fixed 2026-07-13 (DOCFIX-194). |
| Stage 2 "RUNBOOK WRITTEN, NOT YET EXECUTED" | PARTIALLY EXECUTED. The edge + both Office1 networks are live. The three headend VMs are NOT built. |
The trap this correction removes
Stage 2's gate row said the edge was "blocked on gap #17's WAN-side network." Both halves are now false, and someone reading it would go build a network that already exists.
Worse, the Stage 2 gate lists "NetBox authoritative" and "GitBucket serving" -- and NetBox and GitBucket do answer, at baldurkeep.com. But those are PRE-EXISTING services, not Office1 headend VMs. Measured: office1-opnsense is the ONLY VM on the vcloud host. It would be very easy to tick that gate as met and move to Stage 3 with no headend at all. The corrected State section says so explicitly.
What remains of Stage 2 (the real critical path)
The three headend service VMs -- MAAS-region, NetBox, GitBucket -- do not exist. Per the runbook they are blocked on a genuine decision, not on typing: Option A (modules/cloudinit-vm) needs user_data/meta_data/network_config designed and an image source chosen; Option B is manual virt-install, logged as debt. Both cloudinit-vm and base-image now at least VALIDATE (DOCFIX-194) -- they never had before.
Revert
git revert <this commit>
Restores the stale (false) status claims.