Static NICs settings not saved into statefile since v0.5.0 cause re-creation of NICs and failure

[Th0masL]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

• terraform: v1.2.9
• opennebula provider: v0.5.2

Affected Resource(s)

• opennebula_virtual_machine

Terraform Configuration Files

resource "opennebula_virtual_machine" "server" {
   <...>
  nic {
    network_id      = 9
    ip              = "100.64.0.21"
    security_groups = [110]
  }
   <...>
}

Debug Output

For some reason it's detecting that the NIC need to be added/updated, even if it's already here, with the right settings.

  # module.pop.module.server[0].opennebula_virtual_machine.server[0] will be updated in-place
  ~ resource "opennebula_virtual_machine" "server" {
        id             = "18"
        name           = "server1"
        # (20 unchanged attributes hidden)

      + nic {
          + computed_security_groups = (known after apply)
          + ip                       = "100.64.0.21"
          + network_id               = 9
          + security_groups          = [
              + 110,
            ]
        }
        # (5 unchanged blocks hidden)
    }

And then it fails to add/update the NIC:

│ Error: Failed to update NIC
│
│   with module.server[0].opennebula_virtual_machine.server[0],
│   on modules/server/main.tf line 25, in resource "opennebula_virtual_machine" "server":
│   25: resource "opennebula_virtual_machine" "server" {
│
│ virtual machine (ID: 18): vm nic attach: can't attach network with ID:9: OpenNebula error [ACTION]: [one.vm.attachnic] Cannot get IP/MAC lease from virtual network 9.
│

Expected Behavior

There are no changes to the machine, because it got created 5 minutes before, so I would expect the provider to show that all the resources are already up-to-date.

Actual Behavior

It's detecting non-existent changes, and try to apply. But because the IP Address is static and already in use by this very same VM, it's failing to apply the non-existent changes.

Steps to Reproduce

1. Run terraform apply on an existing VM that is using static IP

Important Factoids

References

• #0000

[frousselet]

Hello,

Looks like you are using a static IP outside of the address range.
Since Terraform fails, it tries to recreate the NIC each time it is applied.

[Th0masL]

Looks like you are using a static IP outside of the address range.
Since Terraform fails, it tries to recreate the NIC each time it is applied.

I don't think so, because the previous run of terraform apply was able to create the VM correctly, and the second runs fails with the error above.

I will try again to confirm the behavior, and provide debug logs if needed

[Th0masL]

I have just verified one more time.

Here is the steps:

1. In our .tf file, we hardcode a static IP provided as variable
2. Run terraform destroy to destroy everything and start with a clean state
   • everything get deleted correctly
3. Run terraform apply to recreate the infrastructure
   • everything get created correctly, the VMs has the right static IP and is working fine
4. Run terraform plan to see if there are any changes (there shouldn't be)
   • it's showing that it needs to recreate the nic
5. If I run terraform apply it's failing, saying that the IP is already in use

This is happening with the version v0.5.2.

I've not tried with the latest version of the terraform provider (v1.0.1), but I can also try.

[Th0masL]

I've verified in the terraform state file, and the nic attribute is empty, that's why it's trying to re-add the NIC at every apply:

$ cat /tmp/terraform.tfstate-0.5.2 | jq '.resources[] | select(.type == "opennebula_virtual_machine") | select(.name == "server1") | .instances[].attributes.nic'
[]
[]
[]
[]

[Th0masL]

And if I compare with the output of a terraform state file that has been created with an earlier version of the provider (v0.4.3), the nic attribute is defined :

$ cat /tmp/terraform.tfstate-0.4.3 | jq '.resources[] | select(.type == "opennebula_virtual_machine") | select(.name == "server1") | .instances[].attributes.nic'
[
  {
    "computed_ip": "",
    "computed_mac": "",
    "computed_model": "",
    "computed_physical_device": "",
    "computed_security_groups": [],
    "computed_virtio_queues": "",
    "ip": "XXX.YYY.ZZZ.11",
    "mac": "",
    "model": "",
    "network": "",
    "network_id": 24,
    "nic_id": 0,
    "physical_device": "",
    "security_groups": [
      183
    ],
    "virtio_queues": ""
  },
  {
    "computed_ip": "",
    "computed_mac": "",
    "computed_model": "",
    "computed_physical_device": "",
    "computed_security_groups": [],
    "computed_virtio_queues": "",
    "ip": "100.64.0.11",
    "mac": "",
    "model": "",
    "network": "",
    "network_id": 19,
    "nic_id": 0,
    "physical_device": "",
    "security_groups": [
      184
    ],
    "virtio_queues": ""
  }
]

[Th0masL]

I just tried with the latest version of the provider (v1.0.1), and the nic attributes are also empty in the Terraform state file, so this problem seems to still be here with the latest version

[Th0masL]

I also tried with the provider version v0.5.0, and the nic attribute is also empty in the state file.

So to me it looks like the problem happened somewhere between the version v0.4.3 and v0.5.0.

$ cat /tmp/terraform.tfstate-0.5.0 | jq '.resources[] | select(.type == "opennebula_virtual_machine") | select(.name == "server1") | .instances[].attributes.nic'
[]
[]
[]
[]

[frousselet]

Hello Thomas,

Thanks for the details.

We were able to reproduce it and we are investigating on the issue.

[treywelsh]

Seems to be due to the fact that you describe a NIC with the security_group attribute filled (this makes the bug appear. Without this field I see no diffs, feel free to confirm this on your side).

OpenNebula adds the default security group (ID: 0) to every NIC, but the provider didn't expect that and thought that the NIC wasn't attached due to the diff with it's initial configuration.

I still need to understand why this would happen since 0.4.3 release, at first glance this seems an older problem to me.

As a side note it seems that we'll be able soon to update the NIC security group list for a running VM: OpenNebula/one#5612

Thank you for your help and sorry for this obvious problem