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
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 me too comments, 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.
If an issue is assigned to the modular-magician user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to hashibot, a community member has claimed the issue already.
Terraform Version
Terraform v1.0.2
on linux_amd64
+ provider registry.terraform.io/hashicorp/google v4.1.0
terraform apply-ing this resource and then terraform plan-ing right after should produce no diffs.
Actual Behavior
A diff was produced:
Terraform will perform the following actions:
# google_compute_instance.instance will be updated in-place
~ resource "google_compute_instance" "instance" {
id = "projects/cnrm-jcanseco-2/zones/us-west1-a/instances/my-instance"
+ min_cpu_platform = "AUTOMATIC"
name = "my-instance"
tags = []
# (17 unchanged attributes hidden)
# (3 unchanged blocks hidden)
}
Plan: 0 to add, 1 to change, 0 to destroy.
Steps to Reproduce
terraform apply
terraform plan
Notice how there is a diff for min_cpu_platform. Same issue happens if min_cpu_platform is set to Automatic.
I believe the reason behind this behavior is that according to the documentation for minCpuPlatform, you set the field to AUTOMATIC when you want to clear it in the underlying API.
Therefore, when the user applies a google_compute_instance with min_cpu_platform = "AUTOMATIC", the API clears the field as expected, but now Terraform believes there is a diff since the underlying value is empty whereas the user has a specified value.
I believe the fix here is to supress diffs for min_cpu_platform if the user sets it to AUTOMATIC (or Automatic) and the underlying value is empty string since these should actually be treated as equivalent.
References
b/208316260
The text was updated successfully, but these errors were encountered:
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Community Note
modular-magician
user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned tohashibot
, a community member has claimed the issue already.Terraform Version
Affected Resource(s)
Terraform Configuration Files
Expected Behavior
terraform apply
-ing this resource and thenterraform plan
-ing right after should produce no diffs.Actual Behavior
A diff was produced:
Steps to Reproduce
terraform apply
terraform plan
Notice how there is a diff for
min_cpu_platform
. Same issue happens ifmin_cpu_platform
is set toAutomatic
.I believe the reason behind this behavior is that according to the documentation for minCpuPlatform, you set the field to
AUTOMATIC
when you want to clear it in the underlying API.Therefore, when the user applies a
google_compute_instance
withmin_cpu_platform = "AUTOMATIC"
, the API clears the field as expected, but now Terraform believes there is a diff since the underlying value is empty whereas the user has a specified value.I believe the fix here is to supress diffs for
min_cpu_platform
if the user sets it toAUTOMATIC
(orAutomatic
) and the underlying value is empty string since these should actually be treated as equivalent.References
The text was updated successfully, but these errors were encountered: