Manually Deleted VMs are not recreated

[Thiryn]

Description

Terraform does not detect any drift for VMs created using opennebula_virtual_machine and opennebula_virtual_router_instance that are terminated from the UI (therefor in DONE state).

I assume this is because the VM state is ignored from the terraform state lifecycle. I am also afraid that running the DB cleaning tool (actually deleting VMs in DONE state) will trigger the recreation of the VM (as the ID will be not found), leading to more inconsistency when managing VMs instances via terraform.

Terraform and Provider version

Terraform v1.7.3
on darwin_arm64

• provider registry.terraform.io/opennebula/opennebula v1.4.0

Affected resources and data sources

opennebula_virtual_machine and opennebula_virtual_router_instance

Terraform configuration

resource "opennebula_virtual_router_instance" "v-router-instance" {
  name   = "virtual-router-instance"
  group  = "oneadmin"
  memory = 128
  cpu    = 0.1

  virtual_router_id = 1
}

Expected behavior

When terminating the VM from the UI, subsequent runs of terraform plan should pick up the VM is now in DONE state and recreate it.

Actual behavior

No drift are detected.

Steps to Reproduce

Create a VM with terraform, terminate it from the UI, run terraform plan.

Debug output

No response

Panic output

No response

Important factoids

No response

References

No response

[treywelsh]

"General" issue around state management: #492

[Thiryn]

I think the two issues tackle two different use cases:
#492 relates to the desired state, in a way that it can be changed (Running, Stopped, Hold)

This issue relate to the existence of the VM altogether. To compare to AWS as on the other ticket, an AWS EC2 instance that's deleted has the terminated state and eventually disappears from the AWS API. As the Instance would disappear from the API, the AWS TF provider would automatically recreate the instance (as not found upon read).

The difference here is in the way that deleted VMs are handled in OpenNebula. ON sets the final done state to a VM. Final in the sense that there is no further state that the VM can change to after done. See the ON state management diagram here.

While the detection of the vm existence is done by checking if the vm_state == done, the desired outcome of this issue is not to implement vm_state management.

[github-actions]

This issue is stale because it has been open for 30 days with no activity and it has not the 'status: confirmed' label or it is not in a milestone. Remove the 'status: stale' label or comment, or this will be closed in 5 days.

[fsdaniel]

Not stale

[github-actions]

This issue is stale because it has been open for 30 days with no activity and it has not the 'status: confirmed' label or it is not in a milestone. Remove the 'status: stale' label or comment, or this will be closed in 5 days.