chore: destroy the Ubuntu template VM with saturn's conversion #589

2026-08-25T20:43:44Z

claude-bot commented

2026-08-25 20:43:44 +00:00

VM 605 (ubuntu-24.04-template) is pinned to saturn via node_name, so it cannot survive the conversion — and it has to go before the node leaves the Proxmox cluster, because afterwards the provider cannot reach it and every subsequent plan errors against a missing node. Destroying a VM also needs its node up, so this could not wait until after saturn is powered off.

Surfaced while verifying saturn was empty after destroying VM 151 — qm list still showed it.

Nothing uses it. Its purpose was cloning new Proxmox VMs; Proxmox is being retired; and the one remaining VM definition (vm_152_k8s_3) sets template_name = null explicitly rather than cloning from it.

The module default changes to null for the same reason. It named a template that will no longer exist, so leaving it would only surface as an apply-time failure for whoever created the next VM — and there is no next VM.

Applied

Same local flow as VM 151: plan reviewed, saved with -out, that exact plan applied, temporary Proxmox token revoked afterwards.

🤖 Generated with Claude Code

VM 605 (`ubuntu-24.04-template`) is pinned to saturn via `node_name`, so it cannot survive the conversion — and it has to go **before the node leaves the Proxmox cluster**, because afterwards the provider cannot reach it and every subsequent plan errors against a missing node. Destroying a VM also needs its node up, so this could not wait until after saturn is powered off. Surfaced while verifying saturn was empty after destroying VM 151 — `qm list` still showed it. **Nothing uses it.** Its purpose was cloning new Proxmox VMs; Proxmox is being retired; and the one remaining VM definition (`vm_152_k8s_3`) sets `template_name = null` explicitly rather than cloning from it. The module default changes to `null` for the same reason. It named a template that will no longer exist, so leaving it would only surface as an apply-time failure for whoever created the next VM — and there is no next VM. ## Applied Same local flow as VM 151: plan reviewed, saved with `-out`, that exact plan applied, temporary Proxmox token revoked afterwards. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit 2026-08-25 20:43:45 +00:00

chore: destroy the Ubuntu template VM with saturn's conversion

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

Details

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

Details

a4885926e3

VM 605 is pinned to saturn, so it cannot survive the conversion, and it has to
go before the node leaves the Proxmox cluster — afterwards the provider cannot
reach it and every plan errors.

Nothing uses it. Its purpose was cloning new Proxmox VMs, Proxmox is being
retired, and the one remaining VM definition sets template_name = null
explicitly rather than cloning from it.

The module default is changed to null for the same reason: it named a template
that no longer exists, which would only surface as an apply-time failure for
whoever created the next VM.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

k.renner merged commit 46129f2d4a into master

2026-08-25 20:44:10 +00:00

k.renner referenced this issue from a commit

2026-08-25 20:44:12 +00:00

Merge pull request 'chore: destroy the Ubuntu template VM with saturn's conversion' (#589) from remove-vm-605 into master

review-bot reviewed

2026-08-25 20:45:24 +00:00

review-bot left a comment

🤖 Automated review — model claude-sonnet-5 (complexity: normal), commit a4885926e368000c0859238ac687fb64691c48a6.

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

Summary

Removes the vm_605_template.tf resource (the ubuntu-24.04-template Proxmox template VM, pinned to saturn) ahead of saturn's bare-metal conversion, and changes the proxmox_vm module's template_name variable default from "ubuntu-24-04-template" to null since that template will no longer exist. Small, well-scoped chore; no blocking issues found.

🟡 Suggestions

opentofu/modules/proxmox_vm/variables.tf:49-58: verified the default = null change is safe — main.tf:40-41's dynamic "clone" block is already guarded on var.template_name != null, and the only current module consumer (opentofu/vm_152_k8s_3.tf:10) already sets template_name = null explicitly, so this is a no-op for existing state and only changes behavior for a future VM definition that omits the argument (which the PR body says is intentional).

Tests

No test suite applies to this OpenTofu config change (module variable default + resource deletion). The PR body states the plan was reviewed and applied locally before opening the PR, which is the appropriate verification method for this kind of change. Nothing further to add.

Recommendation

Looks reasonable — no blocking issues; comment above is optional.

🤖 **Automated review** — model `claude-sonnet-5` (complexity: normal), commit `a4885926e368000c0859238ac687fb64691c48a6`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary Removes the `vm_605_template.tf` resource (the `ubuntu-24.04-template` Proxmox template VM, pinned to `saturn`) ahead of saturn's bare-metal conversion, and changes the `proxmox_vm` module's `template_name` variable default from `"ubuntu-24-04-template"` to `null` since that template will no longer exist. Small, well-scoped chore; no blocking issues found. ## 🟡 Suggestions - `opentofu/modules/proxmox_vm/variables.tf:49-58`: verified the `default = null` change is safe — `main.tf:40-41`'s `dynamic "clone"` block is already guarded on `var.template_name != null`, and the only current module consumer (`opentofu/vm_152_k8s_3.tf:10`) already sets `template_name = null` explicitly, so this is a no-op for existing state and only changes behavior for a future VM definition that omits the argument (which the PR body says is intentional). ## Tests No test suite applies to this OpenTofu config change (module variable default + resource deletion). The PR body states the plan was reviewed and applied locally before opening the PR, which is the appropriate verification method for this kind of change. Nothing further to add. ## Recommendation Looks reasonable — no blocking issues; comment above is optional.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: konairius/homelab#589