fix(gcp): upgrade google provider to 8.x and remove service networking peering on destroy - #2380
Merged
Merged
Conversation
Bump every hashicorp/google and hashicorp/google-beta constraint under platform/terraform/gcp from ~> 6.0 to ~> 8.1 and relock all GCP lock files at 8.4.0. Only the google provider entries were relocked; other providers keep their existing locked versions. Breaking changes from the 7.0 and 8.0 upgrade guides that apply here: - google_storage_bucket retention_policy.retention_period is now a string; quote the cicd-oidc evidence bucket value and update the ADR guard assertion that pins it. - google_container_node_pool sandbox_config.sandbox_type is deprecated in 8.x; use sandbox_config.type = "GVISOR". The provider suppresses the diff between the two fields, so this does not replace the node pool. - google_container_cluster logging/monitoring enable_components became sets; configuration passes list literals and nothing indexes them, so no change is needed. - google_project_service disable_on_destroy default removal is already covered by the explicit disable_on_destroy = false. The rendered preparation root also pins google ~> 8.1 so it matches the platform provider major.
…ction Destroying the platform-core root failed on google_service_networking_connection.services with "Producer services (e.g. CloudSQL, Cloud Memstore, etc.) are still using this connection" after Cloud SQL and Memorystore were already deleted, and the destroy retry loop never converged. Set deletion_policy = "REMOVE_PEERING" (google provider >= 8.1) so the delete removes the producer-held VPC peering and the platform network can be deleted. Cloud SQL and Redis depend on the portal_vpc module, so destroy removes them first. Add a credential-free contract test for the portal VPC module asserting the policy, register it in the validation inventory, and stop the gcp-dev destroy workflow comment from claiming its retry loop covers the Service Networking detachment.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
hashicorp/googleandhashicorp/google-betaconstraint underplatform/terraform/gcpfrom~> 6.0to~> 8.1. That covers the 5 environment roots,global/cicd-oidc,global/github-runnerandmodules/portal/gke. The rendered preparation root inshared/cloud/preparation_cloud_installation.pygot the same bump..terraform.lock.hclfiles at google/google-beta 8.4.0. Only the google provider entries changed. Other providers keep their locked versions. Hashes use the existing single-platform (linux_amd64) convention.modules/portal/vpc:google_service_networking_connection.servicesnow setsdeletion_policy = "REMOVE_PEERING". This adds a credential-free contract test (tests/main.tftest.hcl) and registers it invalidation-inventory.yaml.gcp-dev-destroy.yml: the retry-loop comments no longer claim the loop covers Service Networking detachment.terraform destroyof the balrog platform-core root kept failing on the Service Networking connection ("Producer services ... are still using this connection") even after Cloud SQL and Memorystore were deleted. The retry loop did not clear it. The provider's fix isdeletion_policy = "REMOVE_PEERING", which needs google provider >= 8.1.ABANDONwould leave the peering in place, and the peering still blocks deleting the network.REMOVE_PEERINGis safe here becauseportal_cloud_sqlandportal_redisbothdepends_onmodule.portal_vpc, so destroy removes every producer before the connection.Provider 7.0 / 8.0 breaking changes reviewed
I checked all 47
google_*resource and data-source types in use (plus the two extra types in the rendered preparation root) against both upgrade guides. I also diffed the 6.50.0 and 8.4.0 provider schemas for those types.google_storage_bucket.retention_policy.retention_periodnumber -> string (7.0)modules/cicd-oidc-identityevidence bucket"7776000". ADR guard test assertion updated to match.google_container_node_poolsandbox_config.sandbox_typedeprecated in favor oftype(8.x schema)modules/portal/gke/runtime-plugins.tftype = "GVISOR". The provider'sSandboxTypeDiffSuppresssuppresses the diff between the two fields, so this does not replace the ForceNew block. gke contract test updated.google_container_clusterlogging_config/monitoring_config.enable_componentslist -> set (8.0)modules/portal/gke/main.tfgoogle_project_service.disable_on_destroydefault removed (7.0)modules/project-servicesfalse, so behavior is unchanged.google_compute_subnetwork.enable_flow_logsremoved,google_compute_routeradvertised_ip_rangesset,google_secret_manager_secret_version.secret_data_wo_versionstring,google_sql_userpassword_wopairing,node_config.host_maintenance_policyremoved, artifact registrypublic_repositorydefaultsADR Impact
docs/adr/exceptions.yamlADRs touched: none
Exceptions added or renewed: none
Guardrail Changes
Guardrail files changed:
platform/terraform/validation-inventory.yaml(gcp/modules/portal/vpcmoves fromdeferredtoterraform_test), andscripts/adr_guard/tests/test_deploy_workflow.py(retention literal is now a string).Verification
python3 scripts/adr_guard/adr_guard.py --all --level cipasses.scripts/adr_guard/testspass.terraform fmt -check -recursive,terraform validatein all 25 GCP dirs,tflint --recursive(clean), Checkov onplatform/terraform/gcp(336 passed, 0 failed),check_tf_roots --checkand its unittests, and the CIcheck_tf_*scanners with their unittests.terraform testsuite (cicd-oidc 7, github-runner 2, portal/gke 3, portal/vpc 1, range/vpc 3).shifter/packer/tests412 passed.shifter/installation/tests/test_gcp_bundle.py24 passed.shifter/engine/provisioner/tests/test_terraform_base.pypassed.shifter_platformpreparation-cloud and runtime-plugin policy tests: 34 passed.Live read-only plan:
terraform plan -lock=falseof the sauron environment root against its real GCS state succeeded under 8.4.0 with no errors or new warnings. That state currently holds 0 managed resources, so the plan is all creates and cannot show replacement behavior on existing resources. No gcp-dev state bucket exists, and no nazgul tfvars are available locally. So no-replacement on live resources (theretention_periodstate migration, the sandbox field switch, theenable_componentsset conversion) is backed by the provider source and schema checks, not by a populated-state plan.