terraform-provider-google: google_service_networking_connection destroy calls appear to always fail in 5.x despite guidance
Community Note
- 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 tohashibot
, a community member has claimed the issue already.
Terraform Version
Terraform 1.5.5
Affected Resource(s)
- google_service_networking_connection
Terraform Configuration Files
locals {
create_test_network = true
test_vpc_name = local.create_test_network ? google_compute_network.test_vpc[0].name : "default"
}
resource "google_compute_network" "test_vpc" {
count = local.create_test_network ? 1 : 0
name = "test-vpc"
auto_create_subnetworks = false
}
resource "google_compute_global_address" "test_private_service_ip_range" {
count = local.create_test_network ? 1 : 0
name = "test-private-service-ip-range"
purpose = "VPC_PEERING"
address_type = "INTERNAL"
prefix_length = 16
network = google_compute_network.test_vpc[0].id
}
resource "google_service_networking_connection" "test_private_service_access" {
count = local.create_test_network ? 1 : 0
network = google_compute_network.test_vpc[0].id
service = "servicenetworking.googleapis.com"
reserved_peering_ranges = [google_compute_global_address.test_private_service_ip_range[0].name]
}
resource "google_sql_database_instance" "test_instance" {
count = local.create_test_network ? 1 : 0
name = "test-db"
database_version = "POSTGRES_13"
depends_on = [google_service_networking_connection.test_private_service_access]
settings {
tier = "db-f1-micro"
ip_configuration {
ipv4_enabled = false
private_network = google_compute_network.test_vpc[0].id
enable_private_path_for_google_cloud_services = true
}
}
deletion_protection = false
}
Expected Behavior
Terraform should be able to destroy it’s resources gracefully and complete successfully with the 5.x provider
Actual Behavior
With the stated change from the removePeering
to deleteConnection
method in the 5.x provider a regression arguably has occurred.
The 4.x version of the provider was able to cleanly destroy the service networking connection and in turn the VPC it was attached to (if created) and ended successfully.
The switch in 5.x now prevents this with the following error:
│ Error: Unable to remove Service Networking Connection, err: Error waiting for Delete Service Networking Connection: Error code 9, message: Failed to delete connection; Producer services (e.g. CloudSQL, Cloud Memstore, etc.) are still using this connection.
While it’s stated this may be expected as the background deletions of dependent resources such as Cloud SQL is still proceeding in practice it doesn’t seem to be the case. I had created a connection a week ago and was still not able to delete it today (all other resources were deleted) but as soon as I switched over to 4.x I able to remove all resources correctly. Testing further with 5.x I was able to remove the connection manually via UI when Terraform was still posting the same error also. This suggests a bug is actually present and Terraform can no longer delete the connection at all.
With the above hard error it causes Terraform to error and leave with an impartial state leading to a worsened UX also. Terraform was not designed in mind to have resources that cannot be destroyed.
Steps to Reproduce
Attempt to destroy a google_service_networking_connection
resource with the 5.x provider and note that it is never successful.
Head to the UI instead and delete the connection under the VPC and notice it deletes successfully despite the Terraform error.
b/308248337
About this issue
- Original URL
- State: open
- Created 8 months ago
- Reactions: 25
- Comments: 23
I’m not sure I’m following this logic sorry. In our case Terraform simply fails to destroy every time and leaves itself with a problematic partial state, which didn’t happen in 4.x. Others look to be affected as well. How is this not considered a regressive issue? We’re blocked on upgrading to 5.x until this is fixed.
Also hitting this since upgrading to version 5 of the provider. Any news on a fix?
Workaround by using google-beta on provider version 4 and specifying the google-beta provider on the
google_service_networking_connection
resource, as below:I was able to reproduce this issue. removePeering is not documented because the last revision switched the underlying implementation from compute api library to the service networking library. You can see remove peering is still available from the compute api: https://cloud.google.com/compute/docs/reference/rest/v1/networks/removePeering
I guess for some reason it is not implemented in the service networking library. So we can either abandon terraform state or add back removePeering functionality that uses the compute api.
@alnoki more like (.gitlab-ci.yml):
@gygitlab the issue looks like happening among several resources. Can you share a minimum config that I can use to repro?