Add support for states that can be resumed about terraform-provider-opennebula

[jaypif]

Hi @denizcandas

Thank you for this really complete explanation.
This is really interesting. I add this into the 0.3.0 release. It should be tested very well and it represents a huge work on the VM resource.
I cannot give an ETA yet.

[denizcandas]

What would the desired behavior be, if the user uses this flag and the pending flag at the same time? Should the pending flag be overridden? I have also noticed that if we create a VM with pending=true, the VM is still in HOLD even if the resource is applied with pending=false. It has an effect only during creation. However, desired_state attribute would be applied during create and update operations. For now, I'll add a default ignore option for the user, which does not attempt to do anything.

[denizcandas]

If the user enables pending and a state except ignore, the VM will be on HOLD during creation. If the user sets the desired_state to any value except ignore and updates the VM, then the VM will be first released, and then the desired_state will be satisfied. As HOLD is not a state which can be resumed from with onevm's resume command, and not a state which can be attained after the vm has been activated, it is not a possible value for desired_state.

[jaypif]

Hi @denizcandas

If I understand your need you want to manage VM state via Terraform ?

This feature is really interesting, however there are some point to be taken into account:

• The VM is currently running, you update the VM to set desired_state to stopped: you stop the VM: OK
• The VM is currently stopped, you update the VM to set running: do you expect to restart the VM ?
• The VM is currently running, you update the VM to set desired_state to undeploy: you undeploy the VM: OK
• The VM is currently undeployed, you update the VM to set desired_state to running: Do you expect to deploy it ?
• The VM is currently "on hold": some desired state are not available: you are locked.
• ... (there are lots of combinations)

I think you should clarify all possible states with the one currently manage directly by OpenNebula:
http://docs.opennebula.io/5.10/operation/references/vm_states.html?highlight=state#diagram

Keep in mind too that Terraform is not designed to host another state machine: it is only here to deploy and manage infrastructure ;).
The more you add possible values for desired_state, the more complex it is to manage the code.

To ease the review of #33, can you prepare a diagram of what to you expect ? This is to avoid long exchanges

Thanks

[denizcandas]

Hello @jaypif
I have created an example state machine diagram for the plugin and also took out all the relevant states from the opennebula diagram.

For the plugin:

The relevant states that might have to be handled, the desired states are the four states which can be transformed using a onevm command:

Edit: Between hold and inactive states, it should be "desired_state = inactive"
Edit2: Fixed and improved the state transitions. One transition should happen when terraform apply is called, except the dashed one which should be immediately applied if its requirements are met.
Thank you :)

[jaypif]

Hi I will change the milestone to 0.4.0.
The PR #33 should be rebased too

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days