feat(opentofu): decouple the two ForceNew paths from instance_name, and pin the cloud object names #411

Sammanfogat

supernaut sammanfogade 1 incheckning från feat/rename-8c-prep-and-pin in i main

2026-08-10 18:14:07 +00:00

supernaut kommenterad

2026-08-10 17:59:42 +00:00

Ägare

ADR 0039 §8c. Two things: the prep that makes instance_name metadata-only, and the decision not to use it.

Prep

keypair_name (default gitborg-prod-key) and guest_hostname (default gitborg-prod) replace "${var.instance_name}-key" and hostname: ${var.instance_name}. Both were ForceNew — which is why changing instance_name alone measured 6 add / 14 change / 6 destroy on 2026-08-04 with both VMs must be replaced.

Defaults are byte-identical to the old expressions and terraform.tfvars sets only instance_name, so this is a no-op against live state:

tofu plan -detailed-exitcode → zero resource actions
tofu fmt -check clean, tofu validate Success

Decision: the names stay pinned, permanently

Nothing user-facing resolves any of them — no user, no DNS record, no certificate. They appear in the OpenStack dashboard and tofu state. Against that, renaming means a create-new-and-repoint on the keypair, a vault edit that must stay in lockstep with a var edit, and two security-group names whose failure mode is silent and deferred to the next runner boot and the next restore drill.

ADR 0039's own principle applies unchanged — move the label, pin the value. §8a already demonstrated it on this exact keypair: address moved to openstack_compute_keypair_v2.bitborg, id still gitborg-prod-key.

The prep still earns its place: pinning by decision and pinning by accident are different states, and a future rebuild shouldn't be forced into a rename it didn't ask for.

The 8c object inventory in the runbook is relabelled a record, not a task list. The 08-04 measurements are marked pre-prep; post-prep numbers were deliberately not taken, so they're an expectation rather than a result.

Found while verifying — worth its own look

tofu plan is not clean, and it isn't this change. It exits 2 on Changes to Outputs alone, which OpenTofu annotates "without changing any real infrastructure".

OpenTofu outputs are state and only refresh on apply. The stored monitoring_ansible_host_hint still reads grafana.gitborg.se — stale since §4 moved the domain, because no apply has run since. That's the outputs analogue of the #63 image-tag gap, and it costs more than it looks: §8a's documented success condition is "tofu plan reports No changes", so a permanently-dirty plan destroys the signal that condition relies on.

An output-only tofu apply clears it. Noted for §10 rather than smuggled into this PR.

ADR 0039 §8c. Two things: the prep that makes `instance_name` metadata-only, and the decision not to use it. ## Prep `keypair_name` (default `gitborg-prod-key`) and `guest_hostname` (default `gitborg-prod`) replace `"${var.instance_name}-key"` and `hostname: ${var.instance_name}`. Both were ForceNew — which is why changing `instance_name` alone measured **6 add / 14 change / 6 destroy** on 2026-08-04 with both VMs `must be replaced`. Defaults are byte-identical to the old expressions and `terraform.tfvars` sets only `instance_name`, so this is a no-op against live state: - `tofu plan -detailed-exitcode` → **zero resource actions** - `tofu fmt -check` clean, `tofu validate` Success ## Decision: the names stay pinned, permanently Nothing user-facing resolves any of them — no user, no DNS record, no certificate. They appear in the OpenStack dashboard and `tofu state`. Against that, renaming means a create-new-and-repoint on the keypair, a vault edit that must stay in lockstep with a var edit, and **two security-group names whose failure mode is silent and deferred** to the next runner boot and the next restore drill. ADR 0039's own principle applies unchanged — move the label, pin the value. §8a already demonstrated it on this exact keypair: address moved to `openstack_compute_keypair_v2.bitborg`, id still `gitborg-prod-key`. The prep still earns its place: pinning by decision and pinning by accident are different states, and a future rebuild shouldn't be forced into a rename it didn't ask for. The 8c object inventory in the runbook is relabelled a **record**, not a task list. The 08-04 measurements are marked pre-prep; post-prep numbers were deliberately not taken, so they're an expectation rather than a result. ## Found while verifying — worth its own look `tofu plan` is **not clean**, and it isn't this change. It exits `2` on `Changes to Outputs` alone, which OpenTofu annotates "without changing any real infrastructure". **OpenTofu outputs are state and only refresh on `apply`.** The stored `monitoring_ansible_host_hint` still reads `grafana.gitborg.se` — stale since §4 moved the domain, because no apply has run since. That's the outputs analogue of the #63 image-tag gap, and it costs more than it looks: §8a's documented success condition is "`tofu plan` reports **No changes**", so a permanently-dirty plan destroys the signal that condition relies on. An output-only `tofu apply` clears it. Noted for §10 rather than smuggled into this PR.

supernaut lade till 1 incheckning

2026-08-10 17:59:42 +00:00

feat(opentofu): decouple the two ForceNew paths from instance_name, and pin the cloud object names

ci / ci (pull_request) Successful in 1m49s

Detaljer

1ee7ee8d87

ADR 0039 §8c. Two changes: the prep that makes `instance_name`
metadata-only, and the decision not to use it.

## Prep

`keypair_name` (default `gitborg-prod-key`) and `guest_hostname`
(default `gitborg-prod`) replace `"${var.instance_name}-key"` and
`hostname: ${var.instance_name}`. Both of those were ForceNew, which is
why changing `instance_name` alone measured `6 to add, 14 to change,
6 to destroy` on 2026-08-04 with both VMs reporting `must be replaced`.

Defaults are byte-identical to what the old expressions produced, and
`terraform.tfvars` sets only `instance_name`, so this is a no-op against
live state: `tofu plan -detailed-exitcode` reports **zero resource
actions**. `fmt -check` and `validate` clean.

## Decision: the names stay pinned

The live OpenStack object names keep their `gitborg` prefix
permanently. Nothing user-facing resolves any of them — no user, no DNS
record, no certificate; they appear only in the OpenStack dashboard and
`tofu state`. Against that, renaming means a create-new-and-repoint on
the keypair, a vault edit that has to stay in lockstep with a var edit,
and two security-group names whose failure mode is silent and deferred
to the next runner boot and the next restore drill.

ADR 0039's own principle applies unchanged: move the label, pin the
value. §8a already demonstrated it on this very keypair — address moved
to `openstack_compute_keypair_v2.bitborg`, id still `gitborg-prod-key`.

The prep still earns its place: pinning by decision and pinning by
accident are different states, and a future rebuild should not be forced
into a rename it did not ask for.

The 8c object inventory in the runbook is relabelled as a record rather
than a task list, and the 08-04 measurements are marked as pre-prep —
post-prep numbers have deliberately not been taken, so they are an
expectation, not a result.

## Found while verifying

`tofu plan` is not clean, and it is not this change. It exits 2 on
`Changes to Outputs` alone, which OpenTofu annotates "without changing
any real infrastructure". Outputs are state and only refresh on `apply`,
so the stored `monitoring_ansible_host_hint` still reads
`grafana.gitborg.se` — stale since §4 moved the domain. That is the
outputs analogue of the #63 image-tag gap, and it matters because §8a's
documented success condition is `tofu plan` reporting "No changes". An
output-only apply to clear it is noted for §10.

supernaut sammanfogade incheckning c84592e62a till main

2026-08-10 18:14:07 +00:00

supernaut tog bort grenen feat/rename-8c-prep-and-pin

2026-08-10 18:14:07 +00:00

supernaut refererade denna ändringsförfrågan från en incheckning

2026-08-10 18:14:09 +00:00

feat(opentofu): decouple the two ForceNew paths from instance_name, and pin the cloud object names (#411)

supernaut refererade denna ändringsförfrågan från en incheckning

2026-10-02 17:56:57 +00:00

feat(opentofu): decouple the two ForceNew paths from instance_name, and pin the cloud object names (#411)

Logga in för att delta i denna konversation.

Inga granskare