vmware / terraform-provider-avi

Terraform AVI Networks provider
https://registry.terraform.io/providers/vmware/avi/latest/docs
Mozilla Public License 2.0
31 stars 32 forks source link

`avi_vsvip` always detecting changes when utilizing `auto_allocate_ip = true` #607

Open jakauppila opened 1 month ago

jakauppila commented 1 month ago

Describe the bug

We are attempting to leverage the avi_vsvip resource to auto-allocate an IP with an IPAM network subnet and while it works successfully, we're hitting an issue where subsequent executions are detecting changes due to the READ operation pulling back more details than what was initially provided.

Reproduction steps

  1. Create a VIP with the following TF:
resource "avi_vsvip" "vdefend-vip" {
  name = "vip"
  cloud_ref = data.avi_cloud.cloud.id
  vip {
    vip_id = "vip"
    auto_allocate_ip = true
    auto_allocate_ip_type = "V4_ONLY"
    enabled = true
    ipam_network_subnet {
      network_ref = data.avi_network.network.id
    }
    placement_networks {
      network_ref = data.avi_network.network.id
      subnet {
        mask = 21
        ip_addr {
          addr = "10.0.0.0"
          type = "V4"
        }
      }
    }
  }
}
  1. Terraform apply
  2. Terraform apply again
  3. Error!
data.avi_cloud.cloud: Reading...
data.avi_cloud.cloud: Read complete after 1s [id=https://AVICONTROLLER/api/cloud/cloud-cf8825c5-7ea9-40e6-84cd-e1b9bccf7495]
data.avi_network.network: Reading...
data.avi_network.network: Read complete after 0s [id=https://AVICONTROLLER/api/network/network-c43cec83-e5f7-4f5d-b81e-5ab299fd9398]
avi_vsvip.vdefend-vip: Refreshing state... [id=https://AVICONTROLLER/api/vsvip/vsvip-f35e17f4-3dfb-4228-b393-78fbfb80db02]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # avi_vsvip.vdefend-vip will be updated in-place
  ~ resource "avi_vsvip" "vdefend-vip" {
        id                  = "https://AVICONTROLLER/api/vsvip/vsvip-f35e17f4-3dfb-4228-b393-78fbfb80db02"
        name                = "vip"
        # (5 unchanged attributes hidden)

      ~ vip {
            # (15 unchanged attributes hidden)

          - ipam_network_subnet {
              - network_ref  = "https://AVICONTROLLER/api/network/network-c43cec83-e5f7-4f5d-b81e-5ab299fd9398" -> null
                # (2 unchanged attributes hidden)

              - subnet {
                  - mask = "21" -> null

                  - ip_addr {
                      - addr = "10.0.0.0" -> null
                      - type = "V4" -> null
                    }
                }
            }
          + ipam_network_subnet {
              + network_ref  = "https://AVICONTROLLER/api/network/network-c43cec83-e5f7-4f5d-b81e-5ab299fd9398"
              + subnet6_uuid = (known after apply)
              + subnet_uuid  = (known after apply)
            }

            # (2 unchanged blocks hidden)
        }
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Expected behavior

The detection of TF defined configuration vs what is pulled back from the API should be a bit more intelligent to know that it doesn't have to take action.

This might be what DiffSuppressFunc should be leveraged for. It could potentially have custom logic for the resource to know that if auto_allocate_ip = true is set, then automatically ignore the additional details that are coming back from the API when determining if it needs to take action.

Additional context

As a workaround for now, I have the following lifecycle block defined, though that's not ideal if we ever had to modify that value in the TF configuration.

lifecycle {
  ignore_changes = [vip.0.ipam_network_subnet]
}