You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Upgrade of the provider version should not display changes outside of terraform if there has nothing changed.
Actual Behavior
After upgrading to provider version 3.14.0 terraform informs about changes made outside of terraform regarding the new network block attribute secondary_ip_allocation_mode in some cases, even if there has nothing changed:
Terraform detected the following changes made outside of Terraform since the last "terraform apply" which may have affected this plan:
# vcd_vapp_vm.instance has changed
~ resource "vcd_vapp_vm" "instance" {
id = "urn:vcloud:vm:f8a4ade4-edfd-48fd-9cb1-b1003ba2faa8"
name = "testvm01"
# (37 unchanged attributes hidden)
~ network {
name = "test-network"
+ secondary_ip_allocation_mode = "NONE"
# (8 unchanged attributes hidden)
}
# (2 unchanged blocks hidden)
}
Steps to Reproduce
Create configuration from above
terraform apply
Ugrade provider version in version constraint to 3.14.0
The issue only occurs if you are referencing dynamically on all network blocks, for example with an output like in the configuration above.
Additionally it only occurs if you change something in the (network) configuration, not only by upgrading and running terraform plan then.
We had some other configuration (vcd_vapp_vm in a module, similar output in the module, using the module's output in the root config also as a "real" output) where even a change of other attributes of the VM (e. g. CPU count) caused this warning.
The text was updated successfully, but these errors were encountered:
I could reproduce the issue, but I'm unsure whether it is an issue with the Provider itself or Terraform core, as indeed removing the output doesn't cause the issue (if the Provider was buggy I guess it should always report the diff, like something failed during Reads of the remote system).
I'll dig more to see whether I can find something more specific.
In the meantime, I saw that doing a terraform refresh before step 6 (last terraform plan) makes the note/warning to disappear. Not sure if that would work for you?
I could reproduce the issue, but I'm unsure whether it is an issue with the Provider itself or Terraform core, as indeed removing the output doesn't cause the issue (if the Provider was buggy I guess it should always report the diff, like something failed during Reads of the remote system).
Yes, it seems that the issue only occurs, if you reference the network blocks in another resource/output/etc. I would assume that this is also the reason why Terraform only then reports it as "change outside of Terraform". If you do not use it anywhere else, there is no need to report it. But this is only my personal assumption without digging deeper into the exact Terraform functionality.
In the meantime, I saw that doing a terraform refresh before step 6 (last terraform plan) makes the note/warning to disappear. Not sure if that would work for you?
This works and maybe we will use this as a workaround in the meantime. Since we have hundreds of VMs in different projects, this is a slightly bigger task, which has to be coordinated, so a solution on the provider's site would be preferred for us.
Terraform Version
Terraform v1.9.6
Affected Resource(s)
Terraform Configuration Files
Expected Behavior
Upgrade of the provider version should not display changes outside of terraform if there has nothing changed.
Actual Behavior
After upgrading to provider version 3.14.0 terraform informs about changes made outside of terraform regarding the new network block attribute
secondary_ip_allocation_mode
in some cases, even if there has nothing changed:Steps to Reproduce
terraform apply
3.14.0
network
block to the config:terraform init -upgrade
terraform plan
Important Factoids
terraform plan
then.vcd_vapp_vm
in a module, similar output in the module, using the module's output in the root config also as a "real" output) where even a change of other attributes of the VM (e. g. CPU count) caused this warning.The text was updated successfully, but these errors were encountered: