4 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
rootandClaude Sonnet 5	97ede62f6d	Stop tracking deployment status in the Hosts table ... Same problem as the deployedTargets removal, just in markdown instead of Nix: which variant of a buildtype is actually deployed is live infrastructure state, and a committed table can't stay accurate as that changes -- it already required a manual edit on every migration and had drifted before. Keep only what doesn't rot: what each target is for, and stable naming history. Point at the live node / /etc/flake-target instead for actual deployment status. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-20 10:18:33 +00:00
rootandClaude Sonnet 5	2041557ab3	Replace the duplicate-host check with a live Proxmox query, drop deployedTargets ... variables.nix's deployedTargets was a manually-maintained list with no enforcement keeping it in sync with reality -- it caused two separate false refusals in a row (naming a VM as deployed well after it had been destroyed, then matching a target against itself once the list was "corrected"). Static files can't track whether a resource still actually exists. create-proxmox-resource.sh's duplicate-host guard now queries the Proxmox node directly (qm/pct's own name/hostname config, matched against --host) instead. Also fixes a gap in that live check: it originally swallowed ssh failures and would have silently treated "can't reach the node" the same as "checked, nothing there" -- it now refuses instead of guessing when the node can't be reached. deployedTargets is removed entirely from variables.nix since nothing else in the repo consumed it once this script no longer does; README.md's Hosts table remains the sole source of truth for "(real, deployed)" status. CLAUDE.md and the script's own --help/comments updated to match. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-20 10:03:00 +00:00
rootandClaude Sonnet 5	2fd483697b	Don't refuse recreating the canonical already-deployed target itself ... The duplicate-host check in create-proxmox-resource.sh compared by hostName only, so it fired even when the target being created was exactly the one variables.nix's deployedTargets already names (e.g. rebuilding lxc-nix-cache after destroying its old container to pick up new sops secrets) -- there's no other machine at risk of an identity collision in that case, just the normal redeploy workflow. Skip the check when dt == flake_target; the later VMID-existence check still guards against clobbering a resource that's actually live on the node. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-20 09:49:31 +00:00
rootandClaude Sonnet 5	8e3606cbd3	Track nix-cache's real deployment as lxc-nix-cache, not proxmox-nix-cache ... The old proxmox-nix-cache VM was destroyed and nix-cache is being redeployed as an LXC container going forward. Without this update, create-proxmox-resource.sh's duplicate-host check (which only reads this static list, not live Proxmox state) kept refusing to create lxc-nix-cache even though nothing named nix-cache actually exists on the node anymore. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-20 09:40:03 +00:00