search

bpg / terraform-provider-proxmox

Terraform Provider for Proxmox
https://registry.terraform.io/providers/bpg/proxmox
Mozilla Public License 2.0
867 stars 138 forks source link

Wait for VM startup using guest agent `exec` and `cloud-init status --wait` #1576

Open bpg opened 1 month ago

bpg commented 1 month ago

Discussed in https://github.com/bpg/terraform-provider-proxmox/discussions/389

Originally posted by **satwell** June 25, 2023 The PVE API [exposes](https://pve.proxmox.com/pve-docs/api-viewer/#/nodes/{node}/qemu/{vmid}/agent/exec) QEMU Guest Agent's "exec" support, which lets you execute a command on the guest as root. Is there some sensible way that support for this could be added to the provider? Here's my use case. I'm using cloud-init for initial VM setup, but I'd like Terraform to wait until cloud-init has completed before considering creation complete. Cloud-init conveniently [provides a `cloud-init status --wait` command](https://cloudinit.readthedocs.io/en/latest/reference/cli.html#cli-status) that will run until cloud-init is done. I could just use a `remote-exec` provisioner to connect to the VM and run that command. But that requires setting up an ssh connection to it. Which means the ssh port needs to be reachable, keys are set up, the the username matches what the cloud-init image uses, etc. It would be a lot cleaner if I could just use the guest agent for this. In an ideal world, the proxmox provider would be able to define a new provisioner for VM resources that would use the guest agent to run commands. But from my quick investigation, it doesn't sound like there's any way in Terraform to create new provisioner types. Are there other ways that would make sense to add support for the exec API? LIke an additional option in the vm resource type, or a new resource type? Or should I just find or write an external tool that uses the exec API and call it with a `local-exec` provisioner?
bpg commented 1 month ago

I think we can extend the agent block and add something like

agent {
  wait = "cloud-init"
}

Currently the provider implicitly waits on the network interfaces to be available, which may not work reliably for all possible configurations. We might be able to consolidate this checks in one place and configure them through this new wait attribute.