Telmate / terraform-provider-proxmox

Terraform provider plugin for proxmox
MIT License
2.19k stars 531 forks source link

`oncreate` is deprecated but `vm_state` is not a replacement #893

Closed pescobar closed 6 months ago

pescobar commented 10 months ago

If I use oncreate = false I get error deprecated, use vm_state instead but vm_state doesn't work as replacement for oncreate

If I use vm_state = stopped the VM will be stopped every time I execute the terraform code. If I use vm_state = running the machine will be started right after I create it. None of this replace oncreate = false. What I need is that the machine stays off only when I first create it and it stays off until I decide to start it.

To give some extra background, this is my workflow:

This workflow is working fine with proxmox 7.x and Telmate/proxmox 2.9.14 but it doesn't work anymore since we upgraded to proxmox 8.x and TheGameProfi/proxmox 2.9.15 and oncreate is deprecated.

Trying to workaround this problem we tried to use define_connection_info = false so at least terraform doesn't wait for the VM to boot and get an ip but this triggered another issue reported in https://github.com/Telmate/terraform-provider-proxmox/issues/891

Tinyblargon commented 9 months ago

@pescobar If i understand correctly you want the vm_state to not be updated by terraform?

So it would create the VM in stopped mode but not stop it on a subsequent run?

pescobar commented 9 months ago

Hi @Tinyblargon

With older versions of the provider the oncreate flag was working as the "Start after created" checkbox in the VM creation form (see red circle in the attached screenshot)

vm-creation-proxmox

In my understanding vm_state and oncreate are different and vm_state cannot replace oncreate. Before the oncreate option was deprecated I was using oncreate = false and vmstate = running and this config is no longer possible.

I hope I made it more clear. Let me know if you have any doubts.

mleone87 commented 9 months ago

@pescobar @Tinyblargon the "start after created" in the proxmox gui is just a shortcut that makes proxmox start the vm for you, there is no api counterpart for it.

the oncreate and vm_state are the result of different people trying to solve the same problem in various ways without considering the previous work. This is a great example of contributions that we should manage better in the future.

In your specific case, you can define your vm with vm_state = stopped and then after doing your fiddling with MAAS, you update your terraform with vm_state = running and you should get what you want, since the terraform run will detect the vm is already running and simply update the tfstate

Tinyblargon commented 9 months ago

@mleone87 we could introduce a vm_state = started that would set the state to running during creation and not set it during update.

Tinyblargon commented 8 months ago

@pescobar This feature has been added to the roadmap

Tinyblargon commented 8 months ago

@pescobar sorry in interpreted your use case the wrong way round.

Does MAAS fully manage the power state of the vm for you?

Would Terraform not starting the vm on creation and ignoring the power state on subsequent updates solve your problem?

pescobar commented 8 months ago

Thanks for looking into this @Tinyblargon

My ideal use case is that terraform doesn't start the proxmox qm VM on creation but it respects the power state defined in the terraform code in subsequent executions. AFAIK, this is how it was working with proxmox 7.x and provider 2.9.14 but please correct me if I am wrong.

In any case right now it's kind of working for us using the option define_connection_info = false . Our current workflow is:

The only issue is that since we started to use define_connection_info = false we get a warning as I reported in https://github.com/Telmate/terraform-provider-proxmox/issues/891 but this is not blocking us

I prefer the current behavior that works even if it's a kind of hack better than terraform ignoring the power state. I would say if my ideal use case cannot be implemented I prefer to leave it as is

github-actions[bot] commented 6 months ago

This issue is stale because it has been open for 60 days with no activity. Please update the provider to the latest version and, in the issue persist, provide full configuration and debug logs

github-actions[bot] commented 6 months ago

This issue was closed because it has been inactive for 5 days since being marked as stale.