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.
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)
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>
🤖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 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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_2is referenced nowhere else inopentofu/, so this destroys exactly one resource — expect0 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_urlpoints at neptune, not saturn — the endpoint has to survive the conversion.🤖 Generated with Claude Code
🤖 Automated review — model
CLI default(complexity: complex), commitdd727769f650597ba8bcd74347f1b2e8ea79bc09.Summary
Removes the
module.k8s_2OpenTofu resource (VM 151 on saturn) now that saturn is being converted to bare metal, and dropssaturnfrom 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 thatmodule.k8s_2andk8s_2are not referenced anywhere else inopentofu/(no locals, outputs, or other modules depend on it), matching the PR body's claim of0 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..woodpecker/deploy-infrastructure.yml:134-139correctly reflects the new state (jupiter and saturn both bare metal, only neptune left) and is consistent withkubernetes/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.