← Roadmap
⚙️

Proxmox Capacity & Lifecycle

⏳ Upcoming

celilo’s Proxmox placement today is blind: it will drop a fresh container onto a node with no awareness of that node’s free memory or health, and it trusts a stale database row instead of asking Proxmox where things actually live. That blindness caused a real multi-service outage. This work makes placement, resizing, and migration capacity-aware, in-place, and operator-driven without fear — with Proxmox, not a cached row, as the source of truth.

Capacity-aware placement

Before any container is placed, grown, or moved, celilo will query each candidate node’s real free RAM, CPU, and disk and run a fit test with headroom. The margin is configurable per node — tighter on beefy hardware, generous on fragile boxes. An operator can also cordon a node so celilo places nothing new on it even when the math says it fits. Over-commit is hard-rejected by default, with an explicit --allow-overcommit escape hatch. This single check would have prevented the outage outright.

Resize without fear

A module manifest’s size is a suggested default, not a straitjacket. An operator will be able to run celilo proxmox resize <instance> to change memory, cores, or disk in place — no destroy-and-recreate, no data loss. The new size is persisted as a per-instance override in the celilo database, so it survives a re-deploy instead of reverting to the manifest spec.

Move things around

celilo proxmox migrate <instance> will relocate a container to another node — a specific target, or --auto to pick a node that fits and isn’t cordoned. It is restart-based, so a brief downtime is expected and confirmed. This is how you evacuate a failing node or make room, and the recorded intent is reconciled against Proxmox afterward so the two never drift.