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:
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:
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.
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
Code of Conduct
This project has a Code of Conduct that all participants are expected to understand and follow:
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.
Expected Behavior
The zone definition would be applied on the first
terraform apply
, and futureterraform plan
orapply
actions would show no expected changesActual Behavior
Every plan/action shows the same intended change, repeated for all zones:
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:Using the PATCH version of the endpoint with the following customProperties all showed no change to the GET output:
Specifying an additional value, like
foo: bar
, shows the new attribute:Sending either the false or empty customProperties removed the
foo
key. It seemszone_overlapping_migrated
is an immutable key. Further, I can work around this by modifying my zone definition slightly: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