Provider 0.4.0+ is causing flapping on zone custom_properties attribute

Code of Conduct

This project has a Code of Conduct that all participants are expected to understand and follow:

[X] I have read and agree to the project's Code of Conduct

vRA Version

vRA 8.6.2 on-prem

Terraform Version

1.0.5 and 1.0.9

vRA Terraform Provider Version

0.5.1

Affected Resource(s)

vra_zone

Terraform Configuration Files

Each zone is created in a config like this. All zones are reporting the same issue.

# vra_cloud_account_vmc.richardson_2_vcenter:
resource "vra_cloud_account_vmc" "richardson_2_vcenter" {
  accept_self_signed_cert = var.insecure
  api_token               = var.refresh_token
  description             = "Label: \"RichardsonAZ2\""
  name                    = "Richardson-2 vCenter"
  regions = [
    "Datacenter:datacenter-2",
  ]
  vcenter_hostname = var.richardson_2_hostname
  vcenter_password = var.vcenter_password
  vcenter_username = var.vcenter_username
  nsx_hostname     = ""
  sddc_name        = ""

  lifecycle {
    ignore_changes = [
      api_token,
    ]
  }
}

# vra_region.richardson_2_region
data "vra_region" "richardson_2_region" {
  cloud_account_id = resource.vra_cloud_account_vmc.richardson_2_vcenter.id
  region           = "Datacenter:datacenter-2"
}

# vra_zone.richardson_2_lab_zone:
resource "vra_zone" "richardson_2_zone" {
  description      = ""
  folder           = "IaaS/EXSRE/vRA Deploys"
  name             = "Richardson-2 vCenter / Richardson-2"
  placement_policy = "DEFAULT"
  region_id        = data.vra_region.richardson_2_region.id

  tags {
    key   = "vcenter"
    value = "RichardsonAZ2"
  }
  tags {
    key   = "webpool-vra"
    value = "target"
  }

  lifecycle {
    ignore_changes = [
      links,
    ]
  }
}

Expected Behavior

The zone definition would be applied on the first terraform apply, and future terraform plan or apply actions would show no expected changes

Actual Behavior

Every plan/action shows the same intended change, repeated for all zones:

  # module.vra-tf-eisre-infra.vra_zone.richardson_1_zone will be updated in-place
  ~ resource "vra_zone" "richardson_1_zone" {
      ~ custom_properties  = {
          - "zone_overlapping_migrated" = "true" -> null
        }
        id                 = "dcb52e2c-0794-4945-80ec-a35ec3cb01c1"
        name               = "Richardson-1 vCenter / Richardson-1"
        # (9 unchanged attributes hidden)

        # (3 unchanged blocks hidden)
    }

After an apply, the next plan/apply shows the same intended change.

Steps to Reproduce

terraform apply

Important Factoids

This appears to be a bug in the IAAS API. Using postman, I ran a GET against a zone with /iaas/api/zones/b7d98a66-7020-4d47-a46f-ddfe88caea52 and received, among other data, the customProperties of:

    "customProperties": {
        "zone_overlapping_migrated": "true"
    },

Using the PATCH version of the endpoint with the following customProperties all showed no change to the GET output:

   "customProperties": { "zone_overlapping_migrated": "false" },
   "customProperties": {},

Specifying an additional value, like foo: bar, shows the new attribute:

    # sent
    "customProperties": { "foo": "bar" },

    # received
    "customProperties": {
        "foo": "bar",
        "zone_overlapping_migrated": "true"
    },

Sending either the false or empty customProperties removed the foo key. It seems zone_overlapping_migrated is an immutable key. Further, I can work around this by modifying my zone definition slightly:

# vra_zone.richardson_2_lab_zone:
resource "vra_zone" "richardson_2_zone" {
  custom_properties = {"zone_overlapping_migrated" = "true"}
  description      = ""
  folder           = "IaaS/EXSRE/vRA Deploys"
  name             = "Richardson-2 vCenter / Richardson-2"
  placement_policy = "DEFAULT"
  region_id        = data.vra_region.richardson_2_region.id

  tags {
    key   = "vcenter"
    value = "RichardsonAZ2"
  }
  tags {
    key   = "webpool-vra"
    value = "target"
  }

  lifecycle {
    ignore_changes = [
      links,
    ]
  }
}

By setting the custom_properties to this default key and value, terraform stops trying to remove it. While this is a workaround, it does mean that if the value is removed or changed in a future version of vRA, the terraform code may break. I would certainly prefer such a workaround to be implemented in the provider so all users could benefit when something changes. Should I open a case with VMware about this as well? Sometimes API bug reports take a while to filter up to the right team.

References

This issue was previously discovered under https://github.com/vmware/terraform-provider-vra/issues/417, but as a side effect to that reported issue, hence I created a new issue.

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

vmware / terraform-provider-vra