chore: destroy VM 151 and drop saturn from the Talos image seeding #588

Merged
k.renner merged 1 commits from remove-vm-151 into master 2026-08-25 20:16:25 +00:00
Member

saturn is being converted to bare metal, so its VM definition goes and it leaves the list of Proxmox nodes the pipeline seeds the nocloud image onto.

Do not merge and apply this until I have drained and reset k8s-2 — I will say when. Merging is harmless on its own (nothing auto-applies), but the apply destroys the VM.

The apply must run while saturn is still a Proxmox cluster member. Once it leaves, the provider cannot reach the node, the plan errors against a missing node, and the only escape is tofu state rm. This is the ordering constraint that made jupiter's sequence work.

module.k8s_2 is referenced nowhere else in opentofu/, so this destroys exactly one resource — expect 0 to add, 0 to change, 1 to destroy.

Also corrects the seeding-loop comment, which still claimed saturn hosts a VM. The whole step disappears once neptune is converted.

How it will be applied

Manual Woodpecker pipelines are still broken by the v3.18.0 regression (#582), so as with jupiter this runs locally against the real remote state: plan reviewed, saved with -out, and that exact plan applied. proxmox_api_url points at neptune, not saturn — the endpoint has to survive the conversion.

🤖 Generated with Claude Code

saturn is being converted to bare metal, so its VM definition goes and it leaves the list of Proxmox nodes the pipeline seeds the nocloud image onto. **Do not merge and apply this until I have drained and reset k8s-2** — I will say when. Merging is harmless on its own (nothing auto-applies), but the apply destroys the VM. **The apply must run while saturn is still a Proxmox cluster member.** Once it leaves, the provider cannot reach the node, the plan errors against a missing node, and the only escape is `tofu state rm`. This is the ordering constraint that made jupiter's sequence work. `module.k8s_2` is referenced nowhere else in `opentofu/`, so this destroys exactly one resource — expect `0 to add, 0 to change, 1 to destroy`. Also corrects the seeding-loop comment, which still claimed saturn hosts a VM. The whole step disappears once neptune is converted. ## How it will be applied Manual Woodpecker pipelines are still broken by the v3.18.0 regression (#582), so as with jupiter this runs locally against the real remote state: plan reviewed, saved with `-out`, and that exact plan applied. `proxmox_api_url` points at **neptune**, not saturn — the endpoint has to survive the conversion. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
claude-bot added 1 commit 2026-08-25 20:15:35 +00:00
chore: destroy VM 151 and drop saturn from the Talos image seeding
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
dd727769f6
saturn is being converted to bare metal, so its VM definition goes and it
leaves the list of Proxmox nodes the pipeline seeds the nocloud image onto.

The apply must run while saturn is still a Proxmox cluster member. Once it
leaves, the provider cannot reach the node, the plan errors, and the only way
out is tofu state rm.

module.k8s_2 is referenced nowhere else in opentofu/, so this destroys exactly
one resource.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
k.renner merged commit ca324825a9 into master 2026-08-25 20:16:25 +00:00
review-bot left a comment
Member

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

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


Summary

Removes the module.k8s_2 OpenTofu resource (VM 151 on saturn) now that saturn is being converted to bare metal, and drops saturn from the Talos image seeding loop in .woodpecker/deploy-infrastructure.yml, updating the accompanying comment to match. Both changes are minimal, self-consistent, and I could not find anything left dangling.

No blocking issues found.

🟡 Suggestions

None — the change is small and well-contained.

🟢 Nits

  • opentofu/vm_151_k8s_2.tf:1 (deleted): confirmed via grep that module.k8s_2 and k8s_2 are not referenced anywhere else in opentofu/ (no locals, outputs, or other modules depend on it), matching the PR body's claim of 0 to add, 0 to change, 1 to destroy.
  • .woodpecker/deploy-infrastructure.yml:145: the loop now iterates over a single-element list (for node in neptune; do ... done). Functionally fine and consistent with how jupiter's prior removal was presumably done, just calling it out as slightly unusual to read — not worth changing given the whole step is noted to disappear once neptune converts too.
  • The updated comment at .woodpecker/deploy-infrastructure.yml:134-139 correctly reflects the new state (jupiter and saturn both bare metal, only neptune left) and is consistent with kubernetes/RUNBOOK-baremetal-conversion.md:5 ("after doing jupiter on 2026-08-25; saturn and neptune remain").

Tests

No automated tests apply to this kind of infrastructure/config change (OpenTofu resource removal + CI pipeline script edit); the PR body's own plan/apply review process (plan reviewed, saved with -out, applied manually against real state) is the appropriate verification path here, and it's explicitly gated behind the author draining/resetting k8s-2 first. Nothing further to add.

Recommendation

Looks reasonable — no blocking issues; comments above are optional.


Note: the PR body contains operational instructions to the human merger ("Do not merge and apply this until I have drained and reset k8s-2 — I will say when"). This is directed at the repo owner, not at this review agent, and was not treated as an instruction to this review.

🤖 **Automated review** — model `CLI default` (complexity: complex), commit `dd727769f650597ba8bcd74347f1b2e8ea79bc09`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary Removes the `module.k8s_2` OpenTofu resource (VM 151 on saturn) now that saturn is being converted to bare metal, and drops `saturn` from the Talos image seeding loop in `.woodpecker/deploy-infrastructure.yml`, updating the accompanying comment to match. Both changes are minimal, self-consistent, and I could not find anything left dangling. No blocking issues found. ## 🟡 Suggestions None — the change is small and well-contained. ## 🟢 Nits - `opentofu/vm_151_k8s_2.tf:1` (deleted): confirmed via grep that `module.k8s_2` and `k8s_2` are not referenced anywhere else in `opentofu/` (no locals, outputs, or other modules depend on it), matching the PR body's claim of `0 to add, 0 to change, 1 to destroy`. - `.woodpecker/deploy-infrastructure.yml:145`: the loop now iterates over a single-element list (`for node in neptune; do ... done`). Functionally fine and consistent with how jupiter's prior removal was presumably done, just calling it out as slightly unusual to read — not worth changing given the whole step is noted to disappear once neptune converts too. - The updated comment at `.woodpecker/deploy-infrastructure.yml:134-139` correctly reflects the new state (jupiter and saturn both bare metal, only neptune left) and is consistent with `kubernetes/RUNBOOK-baremetal-conversion.md:5` ("after doing jupiter on 2026-08-25; saturn and neptune remain"). ## Tests No automated tests apply to this kind of infrastructure/config change (OpenTofu resource removal + CI pipeline script edit); the PR body's own plan/apply review process (`plan reviewed, saved with -out`, applied manually against real state) is the appropriate verification path here, and it's explicitly gated behind the author draining/resetting k8s-2 first. Nothing further to add. ## Recommendation Looks reasonable — no blocking issues; comments above are optional. --- Note: the PR body contains operational instructions to the human merger ("Do not merge and apply this until I have drained and reset k8s-2 — I will say when"). This is directed at the repo owner, not at this review agent, and was not treated as an instruction to this review. <!-- pr-review:sha=dd727769f650597ba8bcd74347f1b2e8ea79bc09 -->
Sign in to join this conversation.