Provider 0.4.0+ is causing flapping on zone custom_properties attribute
rnelson0 opened this issue · 1 comments
Code of Conduct
This project has a Code of Conduct that all participants are expected to understand and follow:
- 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 #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
I'm on 0.5.0+ and no longer seeing this issue.