feat(opentofu): destroy the rustfs LXCs 800/801/802 #515

2026-08-19T06:53:27Z

claude-bot commented

2026-08-19 06:53:27 +00:00

Stage 2 of the decommission the shim existed for. Deleting the file makes the next apply destroy LXCs 800/801/802.

Plan verified

Plan: 0 to add, 60 to change, 3 to destroy

  # proxmox_virtual_environment_container.rustfs_decommission["800"] will be destroyed
  # proxmox_virtual_environment_container.rustfs_decommission["801"] will be destroyed
  # proxmox_virtual_environment_container.rustfs_decommission["802"] will be destroyed

Three destroys, the three containers, nothing else. The 60 changes are the known cosmetic hairpin _id diffs, documented in #514 and proven harmless by apply 5675.

Why this failed twice before, and why it should work now

The containers were taken out of service months ago — pve_up = 0 on all three, and rustfs-{1,2,3}.srv.renner.uno no longer resolve — but the LXC objects and disks still exist on saturn/jupiter/neptune.

Two earlier destroy attempts (#270) died instantly with context deadline exceeded, because the bpg provider reads timeout_delete from state at destroy time and the imported resources had stored 0 — a zero-second context.

Apply 5675 landed timeout_delete = 1800 and the rest of the timeouts in state, in place, with 0 destroyed. The destroy now has a real deadline for the first time.

Checked before removing

These carry state-backend and terraform-backend tags, so I did not take them at face value:

check	result
tofu backend	Hetzner S3 `renner-uno-tfstate` @ `fsn1.your-objectstorage.com` — not rustfs
Kubernetes / Ansible references	none
`scripts/restore-authentik-db.sh`	mentions `rustfs` only as an `mc` alias name; endpoint is `s3.renner.uno:9000`, the Ceph RGW `migration` store
DNS	already gone for all three names

The tags are historical, from before the state migration to Hetzner. Destroying these cannot pull the state out from under the apply.

Irreversible

This deletes the containers and their disks, including the 50G /mnt/data mount point on each. If anything on those volumes is still wanted, take it off before the apply — afterwards it is gone.

Stage 2 of the decommission the shim existed for. Deleting the file makes the next apply destroy LXCs 800/801/802. ## Plan verified ``` Plan: 0 to add, 60 to change, 3 to destroy # proxmox_virtual_environment_container.rustfs_decommission["800"] will be destroyed # proxmox_virtual_environment_container.rustfs_decommission["801"] will be destroyed # proxmox_virtual_environment_container.rustfs_decommission["802"] will be destroyed ``` Three destroys, the three containers, nothing else. The 60 changes are the known cosmetic hairpin `_id` diffs, documented in #514 and proven harmless by apply 5675. ## Why this failed twice before, and why it should work now The containers were taken out of service **months ago** — `pve_up = 0` on all three, and `rustfs-{1,2,3}.srv.renner.uno` no longer resolve — but the LXC objects and disks still exist on saturn/jupiter/neptune. Two earlier destroy attempts (#270) died instantly with `context deadline exceeded`, because the bpg provider reads `timeout_delete` from **state** at destroy time and the imported resources had stored `0` — a zero-second context. Apply **5675** landed `timeout_delete = 1800` and the rest of the timeouts in state, in place, with `0 destroyed`. The destroy now has a real deadline for the first time. ## Checked before removing These carry `state-backend` and `terraform-backend` tags, so I did not take them at face value: | check | result | |---|---| | tofu backend | Hetzner S3 `renner-uno-tfstate` @ `fsn1.your-objectstorage.com` — **not** rustfs | | Kubernetes / Ansible references | none | | `scripts/restore-authentik-db.sh` | mentions `rustfs` only as an `mc` **alias name**; endpoint is `s3.renner.uno:9000`, the Ceph RGW `migration` store | | DNS | already gone for all three names | The tags are historical, from before the state migration to Hetzner. Destroying these cannot pull the state out from under the apply. ## Irreversible This deletes the containers **and their disks**, including the 50G `/mnt/data` mount point on each. If anything on those volumes is still wanted, take it off before the apply — afterwards it is gone.

claude-bot added 1 commit 2026-08-19 06:53:27 +00:00

feat(opentofu): destroy the rustfs LXCs 800/801/802

ci/woodpecker/manual/deploy-infrastructure Pipeline was successful

Details

ci/woodpecker/pr/ci-scripts-test Pipeline was successful

Details

ci/woodpecker/pr/pr-review Pipeline was successful

Details

fd35f5f21b

Stage 2 of the decommission the shim was written for. Deleting the file makes
the next apply destroy the three containers.

The containers were taken out of service months ago — they are stopped
(pve_up = 0 for all three) and rustfs-{1,2,3}.srv.renner.uno no longer resolve
— but the LXC objects and their disks still exist on saturn/jupiter/neptune.
Two earlier destroy attempts (#270) died instantly with "context deadline
exceeded", because the bpg provider reads timeout_delete from STATE and the
imported resources had stored 0.

That is now fixed: apply 5675 landed timeout_delete = 1800 and the rest of the
timeouts in state, in place, with 0 destroyed. The destroy has a real deadline
to work with for the first time.

Checked before removing, since the containers are tagged `state-backend` and
`terraform-backend`:

  - The tofu backend is Hetzner S3 (renner-uno-tfstate at
    fsn1.your-objectstorage.com), not rustfs. Destroying these cannot pull the
    state out from under the apply. The tags are historical, from before that
    migration.
  - No Kubernetes or Ansible resource references rustfs.
  - scripts/restore-authentik-db.sh mentions rustfs only as an `mc` alias name;
    its endpoint is s3.renner.uno:9000, the Ceph RGW `migration` store.
  - DNS for the three names is already gone.

Co-Authored-By: Claude Bot <claude-bot@renner.uno>

review-bot reviewed

2026-08-19 06:55:15 +00:00

review-bot left a comment

🤖 Automated review — model CLI default (complexity: complex), commit fd35f5f21b1429fb91ea438a624ddb458750302f.

Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.

Summary

This PR deletes opentofu/lxc_800_rustfs_decommission.tf in its entirety — a 122-line "shim" resource block that previously existed only to write correct timeout_* values into state for the three decommissioned rustfs LXCs (800/801/802). Removing the file means the next tofu plan/apply will destroy those three containers (and their disks, per the PR body). This is a pure deletion with no other code changes; I verified the claims in the PR body against the checkout and they hold up. No blocking issues.

🟡 Suggestions

None of substance. The change is a clean, self-contained deletion — I grepped the whole opentofu/ tree plus scripts/ for rustfs, 800, 801, 802, and rustfs_decommission and found no other reference to this resource or its for_each keys, so nothing is left dangling.

Verification performed

Backend claim (opentofu/providers.tf:2-8): confirmed the S3 backend is https://fsn1.your-objectstorage.com (Hetzner), not any rustfs host — matches the PR body's table.
scripts/restore-authentik-db.sh:14,36-37: confirmed rustfs there is only an mc alias name; the actual endpoint is $S3_ENDPOINT = http://s3.renner.uno:9000, unrelated to the LXCs being destroyed — matches the PR body.
No dangling references: grepped the repo for rustfs, rustfs_decommission, and the vm_ids 800/801/802 — the only other hits are coincidental digit matches (e.g. 8006 in a Proxmox API URL, provider lock-file hashes) and the restore-authentik-db.sh alias already covered above. No other .tf file, module, or local references this resource.
Blast radius / gating: .woodpecker/deploy-infrastructure.yml gates apply behind TOFU_APPLY == "true" (line 88) and always runs plan first — so merging this PR alone produces a plan showing the 3 destroys but does not execute them automatically. The irreversibility warning in the PR body (disks, including the 50G /mnt/data mount, are destroyed once applied) is accurate and appropriately called out.
Repo history is unavailable in this checkout (shallow clone, single commit visible), so I could not independently verify the "apply 5675 landed timeout_delete=1800 with 0 destroyed" claim from git log — I'm relying on the PR author's account there, which is consistent with everything else that is checkable (the shim's own comments describe exactly this mechanism, and the file being deleted now rather than earlier is consistent with a prior in-place-only apply having already happened).

Tests

Not applicable — this is an OpenTofu config deletion, verified by tofu plan (per the PR body) rather than unit tests, which matches how the rest of opentofu/ is validated in this repo (no .tf test framework present).

Recommendation

Looks reasonable — no blocking issues; this is a well-documented, irreversible infrastructure destroy behind the existing plan/apply gate, and the PR body's factual claims check out against the repo.

🤖 **Automated review** — model `CLI default` (complexity: complex), commit `fd35f5f21b1429fb91ea438a624ddb458750302f`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary This PR deletes `opentofu/lxc_800_rustfs_decommission.tf` in its entirety — a 122-line "shim" resource block that previously existed only to write correct `timeout_*` values into state for the three decommissioned `rustfs` LXCs (800/801/802). Removing the file means the next `tofu plan`/`apply` will destroy those three containers (and their disks, per the PR body). This is a pure deletion with no other code changes; I verified the claims in the PR body against the checkout and they hold up. No blocking issues. ## 🟡 Suggestions - None of substance. The change is a clean, self-contained deletion — I grepped the whole `opentofu/` tree plus `scripts/` for `rustfs`, `800`, `801`, `802`, and `rustfs_decommission` and found no other reference to this resource or its `for_each` keys, so nothing is left dangling. ## Verification performed - **Backend claim** (`opentofu/providers.tf:2-8`): confirmed the S3 backend is `https://fsn1.your-objectstorage.com` (Hetzner), not any rustfs host — matches the PR body's table. - **`scripts/restore-authentik-db.sh:14,36-37`**: confirmed `rustfs` there is only an `mc alias` name; the actual endpoint is `$S3_ENDPOINT = http://s3.renner.uno:9000`, unrelated to the LXCs being destroyed — matches the PR body. - **No dangling references**: grepped the repo for `rustfs`, `rustfs_decommission`, and the vm_ids `800`/`801`/`802` — the only other hits are coincidental digit matches (e.g. `8006` in a Proxmox API URL, provider lock-file hashes) and the `restore-authentik-db.sh` alias already covered above. No other `.tf` file, module, or local references this resource. - **Blast radius / gating**: `.woodpecker/deploy-infrastructure.yml` gates `apply` behind `TOFU_APPLY == "true"` (line 88) and always runs `plan` first — so merging this PR alone produces a plan showing the 3 destroys but does not execute them automatically. The irreversibility warning in the PR body (disks, including the 50G `/mnt/data` mount, are destroyed once applied) is accurate and appropriately called out. - Repo history is unavailable in this checkout (shallow clone, single commit visible), so I could not independently verify the "apply 5675 landed timeout_delete=1800 with 0 destroyed" claim from git log — I'm relying on the PR author's account there, which is consistent with everything else that *is* checkable (the shim's own comments describe exactly this mechanism, and the file being deleted now rather than earlier is consistent with a prior in-place-only apply having already happened). ## Tests Not applicable — this is an OpenTofu config deletion, verified by `tofu plan` (per the PR body) rather than unit tests, which matches how the rest of `opentofu/` is validated in this repo (no `.tf` test framework present). ## Recommendation Looks reasonable — no blocking issues; this is a well-documented, irreversible infrastructure destroy behind the existing plan/apply gate, and the PR body's factual claims check out against the repo.

k.renner merged commit 3d05d47239 into master

2026-08-19 06:55:17 +00:00

k.renner referenced this issue from a commit

2026-08-19 06:55:18 +00:00

Merge pull request 'feat(opentofu): destroy the rustfs LXCs 800/801/802' (#515) from decommission-rustfs-lxc into master

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: konairius/homelab#515