Changelog 2026-07-09 -- OpenTofu cloud-init/base-image VM modules (DOCFIX-145)

No live infrastructure touched -- unapplied IaC source only. Continues the DOCFIX-142/144 OpenTofu scaffold.

Item

1. DOCFIX-145 -- opentofu/modules/base-image + opentofu/modules/cloudinit-vm

FILES (new): opentofu/modules/base-image/{main,variables,outputs}.tf, opentofu/modules/cloudinit-vm/{main,variables,outputs}.tf.

WHAT: the second VM-creation pattern this repo needs, for Office1's own service VMs (MAAS-region, NetBox, GitBucket -- D-103), genuinely distinct from modules/node-vm's blank-disk PXE pattern (that one is for MAAS-managed OpenStack nodes MAAS itself images after enlistment; these are self-managed VMs that need a real bootable OS + cloud-init). Split into two modules matching how the provider's own real example separates concerns: base-image downloads one shared cloud image once (libvirt_volume with create.content.url); cloudinit-vm creates a per-instance copy-on-write overlay disk (backing_store), a libvirt_cloudinit_disk NoCloud seed, and the domain referencing both.

VERIFICATION: every resource/attribute shape used is taken directly from examples/alpine_cloudinit.tf (fetched and read as real, runnable code last turn while building the node-VM module) -- the same high-confidence source that surfaced the syntax-bug fix in DOCFIX-144. One design choice improved during authoring: the base image's .path is threaded across the module boundary as a real output/input (module.<base-image>.path -> cloudinit-vm's base_volume_path variable) rather than reconstructed from a pool name + volume name string, avoiding an unconfirmed path-convention guess entirely.

DELIBERATELY NOT DONE:

• user_data/meta_data/network_config have no defaults and no generic fallback content. What Office1's three service VMs actually need installed/configured is real design work that hasn't happened; a plausible-looking default (e.g. the common dhcp4: true netplan stanza) would also silently fail here regardless, since this repo's plane networks carry no libvirt-managed DHCP (NetBox is the IPAM apex).
• OPNsense applicability is explicitly NOT confirmed. This whole cloud-init/NoCloud mechanism is standard for Linux cloud images; OPNsense is FreeBSD-based, and its support for the same mechanism was not checked this session. Flagged prominently in both modules' headers and opentofu/README.md -- do not assume cloudinit-vm covers OPNsense without verifying that specifically first.
• Neither module instantiated in root main.tf. No image source has been chosen for any Office1 service VM.

Workflow doc (docs/dc-dc-deployment-workflow.md) Stage 2 authoring status, gap register items 2 and 4, and the status summary table updated to match; companion visual tracker (same Artifact URL) redeployed.

HARNESS: none added -- pure .tf source, same as the prior OpenTofu deliveries; scripts/opentofu-validate.sh covers all of opentofu/ generically once a tofu binary is available to run it.

REVERT: git rm -r opentofu/modules/base-image opentofu/modules/cloudinit-vm; revert the workflow-doc sections listed above if reverting fully.

Next actionable step (unchanged, still logged not actioned)

Same as DOCFIX-144: on a machine with the tofu binary and registry network access, run bash scripts/opentofu-validate.sh against all of opentofu/, then tofu providers schema -json to confirm the remaining unverified details (the boot-order shape in node-vm; whether libvirt_cloudinit_disk

• this whole pattern actually produces a bootable OPNsense image, which needs a real test boot, not just a schema check).