-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
permadiff on google_sql_database_instance #12099
Comments
Same issue here. Perhaps this is the effect of |
Thanks for that reference. Also mentioning |
The issue does seem to be that Wondering if there's any way to unset it (e.g., using |
Interestingly, I noticed that this issue occurs via changes from the Cloud Console. The reproduction steps are as follows:
terraform {
required_providers {
google = { version = "~> 4.27.0" }
}
}
provider "google" {
credentials = file("credentials.json")
project = "<PROJECT>"
region = "us-central1"
zone = "us-central1-c"
}
resource "google_sql_database_instance" "main" {
name = "main-instance"
database_version = "POSTGRES_14"
region = "us-central1"
settings {
tier = "db-f1-micro"
availability_type = "REGIONAL"
location_preference {
zone = "us-central1-a"
}
}
}
This may seem unnatural, but sometimes after changing settings from the Cloud Console, we change the Terraform configuration to follow.
terraform {
required_providers {
- google = { version = "~> 4.27.0" }
+ google = { version = "~> 4.29.0" }
}
}
This is an issue with updates in the Cloud Console and may be beyond Terraform's responsibility. |
That tracks with what I know - I can imagine that someone may have viewed or edited (as a noop) the instance in the cloud console, and also agree that this may be outside of what the provider itself can solve (i.e., it's not really a bug or provider permadiff, however, as I don't recall anyone setting this explicitly for this instance vs. any other, the behavior is still unexpected / undesirable. |
So maybe closing this and creating an issuetracker ticket is the right thing? I asked on the GCP slack if there's an "under the hood" way to zero out that field again, but haven't gotten a response yet. |
@wata727 @wyardley I can't repro this using the config here. Reviewed the provider code, |
Thanks all @wata727 I created |
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. |
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.I'm running into an issue with permadiff
Note: this is likely not reproducible - we have the same code running in multiple projects and with multiple instances, and this is only affecting one of them. However, it is sticky / consistent, and seems to have popped up after updating from 4.27.0 to 4.28.0, though that's not 💯 for sure.
Terraform Version
Affected Resource(s)
Terraform Configuration Files
Debug Output
Between a "working" (no permadiff) and instance with the permadiff, the
locationPreference
bit in the API response from Google looks the same to me:"good"
I can't easily provide full debug output, but happy to do some more troubleshooting, or provide more information if needed.
Panic Output
Expected Behavior
Terraform plans clean, or applies once and does not show a diff on next plan / apply.
Actual Behavior
Terraform has a permadiff on this resource for this specific instance
Steps to Reproduce
terraform apply
Important Factoids
References
The text was updated successfully, but these errors were encountered: