[Feature Request] - Option to ignore `allowed_bandwidth`/`kvm` properties changes

[thehunmonkgroup]

Describe the bug When upgrading Terraform versions, and running terraform apply on a Vultr instance that has had no changes to its configuration, the allowed_bandwidth and kvm properties are reported as having changed outside of Terraform.

Running terraform apply again after the upgrade results in No changes as expected, but having to manually confirm these erroneous changes across many servers is a bit tedious :)

To Reproduce Steps to reproduce the behavior:

1. Install latest version of provider (2.19.0 as of this writing)
2. Upgrade Terraform
3. Run terraform init -reconfigure -upgrade && terraform apply on an existing Vultr instance which has not had any configuration changes since last terraform apply
4. Note the following output or similar:

   
   Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the last "terraform apply" which may have affected this plan:

module.role.module.instance-vultr.vultr_instance.gw[0] has changed

~ resource "vultr_instance" "gw" { ~ allowed_bandwidth = 699 -> 723 id = "xxxxxxxxxxxxxxxxx" ~ kvm = "https://my.vultr.com/subs/vps/novnc/api.php?data=xxxxxxxx" -> "https://my.vultr.com/subs/vps/novnc/api.php?data=xxxxxxx" tags = []

(27 unchanged attributes hidden)

}

**Expected behavior**

`No changes` should be reported.

[thehunmonkgroup]

These spurious changes appear to no longer happen once I got to Terraform v1.3.10.

Guessing this is an incompatibility between the newer version of the provider and older versions of Terraform.

I'll leave the issue open in case you want to adjust the provider for backwards compat.

[thehunmonkgroup]

It appears I spoke too soon, the behavior appeared again at Terraform v1.4.7.

[optik-aper]

@thehunmonkgroup Thanks for the report. Both of those are "computed" fields so aside from removing them, I'm not sure of a way to avoid these periodic updates. But, for your case, you could use the lifecycle argument in your terraform config to ensure that these changes stop interrupting your workflow.

[thehunmonkgroup]

@optik-aper thanks for the sensible workaround

[thehunmonkgroup]

But, for your case, you could use the lifecycle argument in your terraform config to ensure that these changes stop interrupting your workflow.

Sadly, this does not work, adding this to my resource config:

  lifecycle {
    ignore_changes = [
      allowed_bandwidth,
      kvm,
    ]
  }

Produces these errors:

Adding an attribute name to ignore_changes tells Terraform to ignore future changes to the argument in configuration after the object has been created, retaining the value originally configured.\n\nThe attribute allowed_bandwidth is decided by the provider alone and therefore there can be no configured value to compare with. Including this attribute in ignore_changes has no effect. Remove the attribute from ignore_changes to quiet this warning.
Adding an attribute name to ignore_changes tells Terraform to ignore future changes to the argument in configuration after the object has been created, retaining the value originally configured.\n\nThe attribute kvm is decided by the provider alone and therefore there can be no configured value to compare with. Including this attribute in ignore_changes has no effect. Remove the attribute from ignore_changes to quiet this warning.

I should also add that these are not 'periodic' updates -- they seem to happen quite a bit.

Is there any real value in storing these in the Terraform state? As far as I understand, they are computed values and cannot be controlled by the user, nor managed by Terraform. Can't they be suppressed from inclusion in the state?

[optik-aper]

@thehunmonkgroup Oh shoot, you're right. It's only for changes you don't want to sync up to the remote for whatever reason. I'm looking at other options but, ultimately, I don't think removing the attributes is the correct course since some folks might be using them as values for other operations. There are a lot of purely computed values in the data which don't change as often, so are not as bothersome, but are still important for some use-cases. In general, the idea is to expose anything that the API returns for the sake of consistency.

If you know that your configuration hasn't changed when you're applying these changes, perhaps using the -auto-approve flag would make this less annoying? It should automatically apply the remote changes to your tfstate without asking you to approve. The danger there is if you accidentally auto-approve a forced replacement, you could inadvertently wipe out a resource with one command and no warning.

[thehunmonkgroup]

If you know that your configuration hasn't changed when you're applying these changes, perhaps using the -auto-approve flag would make this less annoying? It should automatically apply the remote changes to your tfstate without asking you to approve. The danger there is if you accidentally auto-approve a forced replacement, you could inadvertently wipe out a resource with one command and no warning.

Yeah, I'm not quite that much of a cowboy ;)

Maybe add a plugin specific arg that allows users to list values they DON'T want stored in the state?

[optik-aper]

This seems to be a widespread concern https://discuss.hashicorp.com/t/objects-have-changed-outside-of-terraform-ignore-changes-ignored/24776

[optik-aper]

Some official context on this: https://support.hashicorp.com/hc/en-us/articles/4405950960147-New-Feature-Objects-have-changed-outside-of-Terraform