Context
VM list + simple lifecycle (start/stop/suspend/resume) are now direct-REST v1 (/v1/proxmox/hosts/{id}/vms...). The heavy ops remain on the v0 Ansible path: create, clone, delete, setters, snapshots, network, firewall, storage. The REST API is limiting for these (no idempotency, no orchestration, no in-guest reach, long-running UPID polling) — they should stay Ansible, but be exposed under a clean v1 contract.
What
- Add v1 endpoints that run the existing
proxmox_controller playbooks via ansible-runner (the /v1/deployments path already does this) for create/clone/snapshots/etc., keyed by the registered host id.
- Retire the v0
/v0/admin/proxmox/* surface once the UI is fully on v1.
Acceptance
- UI talks only to
/v1; mechanism (direct REST vs Ansible) is an internal detail chosen per op.
- create/clone keep idempotency + task polling via the playbooks.
Rule of thumb: single fast control-plane op → direct REST; orchestration / idempotency / in-guest / multi-resource → Ansible under a v1 endpoint.
Context
VM list + simple lifecycle (start/stop/suspend/resume) are now direct-REST v1 (
/v1/proxmox/hosts/{id}/vms...). The heavy ops remain on the v0 Ansible path: create, clone, delete, setters, snapshots, network, firewall, storage. The REST API is limiting for these (no idempotency, no orchestration, no in-guest reach, long-running UPID polling) — they should stay Ansible, but be exposed under a clean v1 contract.What
proxmox_controllerplaybooks viaansible-runner(the/v1/deploymentspath already does this) for create/clone/snapshots/etc., keyed by the registered host id./v0/admin/proxmox/*surface once the UI is fully on v1.Acceptance
/v1; mechanism (direct REST vs Ansible) is an internal detail chosen per op.Rule of thumb: single fast control-plane op → direct REST; orchestration / idempotency / in-guest / multi-resource → Ansible under a v1 endpoint.