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 to hashibot, 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

Most upvoted comments

In that sense - this isn’t really a bug as far as I can tell. The resource can be deleted - we do so successfully in our nightly tests. But it sounds like there’s a use case for abandoning in some cases.

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:

required_providers {
    google = {
      source = "hashicorp/google"
      version = "~>5"
    }
    google-beta = {
      source = "hashicorp/google-beta"
      version = "~>4"
    }
  }

provider "google" {
  project = <PROJECT_ID>
  region  = <REGION>
}

provider "google-beta" {
  project = <PROJECT_ID>
  region  = <REGION>
}

resource "google_service_networking_connection" "google_managed_services_peering" {
  network                 = <VPC_ID>
  service                 = "servicenetworking.googleapis.com"
  reserved_peering_ranges = <RESERVED_PEERING_RANGES>
  provider = google-beta
}

documented in the API

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):

destroy-first:
  extends: .google-base
  stage: cleanup
  when: manual
  script:
    - gcloud compute networks peerings delete servicenetworking-googleapis-com --network $CI_COMMIT_REF_SLUG-default
  rules:
    - if: $CI_COMMIT_BRANCH =~ "/^mr-meeseeks\/.*/"

terraform:destroy:
  extends: .terraform-base
  stage: cleanup
  needs:
    - destroy-first
  script:
    - gitlab-terraform destroy
  rules:
    - if: $CI_COMMIT_BRANCH =~ "/^mr-meeseeks\/.*/"

@gygitlab the issue looks like happening among several resources. Can you share a minimum config that I can use to repro?