Primary IP cannot be changed via opennebula_virtual_network_address_range

[TGM]

Description

Provider version: 1.2.2
OpenNebula version: 6.4.0.1

opennebula_virtual_network_address_range cannot update existing IPs

╷
│ Error: can't remove virtual network address range
│ 
│   with module.vmk["vmk-dev-intel-01"].opennebula_virtual_network_address_range.ar["eth3"],
│   on ../single-vm/main.tf line 136, in resource "opennebula_virtual_network_address_range" "ar":
│  136: resource "opennebula_virtual_network_address_range" "ar" {
│ 
│ Virtual network (ID:13): AR (ID:0): can't remove AR 0: OpenNebula error
│ [INTERNAL]: [one.vn.free_ar] Address Range has leases in use

Terraform and Provider version

resource "opennebula_virtual_network_address_range" "ar" {
  for_each = local.combined_ips

  virtual_network_id = data.opennebula_virtual_network.vnet[each.value.interface].id
  ip4                = split("/", each.value.ip)[0]
  size               = 1
}

resource "opennebula_virtual_machine" "vm" {
...

  dynamic "nic" {
    for_each = {
      for k, v in opennebula_virtual_network_address_range.ar : k => v
    }

    content {
      model         = "virtio"
      virtio_queues = local.virtio_queues
      network_id    = nic.value.virtual_network_id
      ip            = nic.value.ip4
    }
  }
...

Affected resources and data sources

No response

Terraform configuration

No response

Expected behavior

The existing IP should be released and replaced with the new one.

Actual behavior

╷
│ Error: can't remove virtual network address range
│ 
│   with module.vmk["vmk-dev-intel-01"].opennebula_virtual_network_address_range.ar["eth3"],
│   on ../single-vm/main.tf line 136, in resource "opennebula_virtual_network_address_range" "ar":
│  136: resource "opennebula_virtual_network_address_range" "ar" {
│ 
│ Virtual network (ID:13): AR (ID:0): can't remove AR 0: OpenNebula error
│ [INTERNAL]: [one.vn.free_ar] Address Range has leases in use

Steps to Reproduce

1. Create a new VM with one static IP and the size one 1.
2. Update the static IP to a new one.
3. Results in the above error.

Debug output

No response

Panic output

No response

Important factoids

No response

References

No response

[TGM]

Hey guys,
Is anybody working on this?

[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.

[treywelsh]

The current provider behavior when updating the ip4 attribute is to detach then reattach the address range.
There's an update_ar XML-RPC method and the provider use it but it doesn't allow to update all AR attributes (at least it didn't allow it when we created the address range resource).

Looking at your problem: the provider is not able to detach the AR because Address Range has leases in use, it means that the VM is using an IP for the AR we're trying to update.

I'm not sure that we should manage the VM NIC addresses from the AR resource so I'm not sure we should directly modify the provider here but I'm open to discuss.

Any idea @frousselet ?

[frousselet]

not able to detach the AR

I suppose you mean 'not able to detach the NIC'

I was thinking about a new opennebula_nic_attachement and opennebula_nic resources as NIC have an ID.

locals {
  ip = "192.168.1.5"
}

resource "opennebula_virtual_network_address_range" "ar" {
  virtual_network_id = data.opennebula_virtual_network.vnet.id
  ip4                = local.ip # Force recreate when changed
  size               = 1
}

resource "opennebula_nic" "nic" {
  model         = "virtio"
  virtio_queues = local.virtio_queues
  network_id    = data.opennebula_virtual_network.vnet.id
  ip4           = local.ip # Force recreate when changed

  depends_on = [
    opennebula_virtual_network_address_range.ar
  ]
}

resource "opennebula_virtual_machine" "vm" {
...
}

resource "opennebula_nic_attachement" "vmnic" {
  vm_id  = opennebula_virtual_machine.vm.id
  nic_id = opennebula_nic.nic.id
}

If you change the opennebula_nic ip4 attribute it forces recreate the opennebula_nic_attachement resource.
Also, as there is no direct link between opennebula_nic and opennebula_virtual_network_address_range, adding a depends_on meta-argument might help in the case you create one AR per NIC.

[TGM]

I don't see any problems with this approach.
@treywelsh ?

[TGM]

Hi guys, is anybody working on this?