2026-07-14 -- D-119 OpenTofu rename APPLIED (operator-gated destroying apply)

The tofu apply deferred by the D-119 commit. Executed after explicit operator authorization.

Pre-apply discipline (verify before mutate)

A LIVE re-check immediately before the apply (not the earlier measurement):

dc1-* / mesh-dc* networks   -> 0 DHCP leases each
dc1-pool / dc2-pool         -> 0 volumes each
every libvirt domain        -> none references a dc1-*/mesh-dc* network

Then a fresh tofu plan: 11 to add, 0 to change, 11 to destroy -- all must be replaced (the moved{} blocks). Confirmed empty, so the replace is safe (standing lesson 2: an apply touching a live libvirt object's devices is an outage -- none of these carried anything).

Result

Apply complete! Resources: 11 added, 0 changed, 11 destroyed.

Verified ON THE HOST, not just in state:

• state holds all 11 under vr1_dc0_* / vr1_dc1_* / mesh_vr1_*;
• tofu plan -> "No changes" (repo/state back in sync);
• libvirt shows vr1-dc0-{provider-public,metal-admin,metal-internal,data-tenant,storage,replication}, mesh-vr1-dc0-office1, mesh-vr1-dc0-vr1-dc1, mesh-vr1-dc1-office1, vr1-dc0-pool, vr1-dc1-pool;
• ZERO old dc1-*/dc2-*/mesh-dc* network or pool names remain.

No collateral

Office1 was never in the plan and is untouched: office1-local, office1-wan, wan, the office1-opnsense edge and voffice1 all present; edge (10.10.0.1) and voffice1 (10.10.0.20) both reachable after the apply.

Why this went before Stage 3

Carrying divergent repo/state into Stage 3 would let a Stage-3 tofu apply silently bundle this 11-resource rename with real DC provisioning. Applying it now, while the objects are empty, kept the rename a clean standalone change.

Revert

The moved{} blocks are symmetric; reverting the D-119 code commit and re-applying renames back. There is nothing to preserve in these objects (they are empty), so a revert is a pure rename.