BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News HashiCorp Relased Terraform Google Cloud Provider 8.0 in General Availability

HashiCorp Relased Terraform Google Cloud Provider 8.0 in General Availability

Listen to this article -  0:00

HashiCorp has announced the general availability of version 8.0 of the Terraform provider for Google Cloud. The major release updates the default load balancing for two Compute Engine resources. It also removes resources linked to retired Google Cloud services. Additionally, it changes several order-insensitive attributes from lists to sets. This prevents ongoing plan differences. Because it is a breaking release, HashiCorp recommends moving to the latest 7.x release first and clearing deprecation warnings before upgrading.

The most visible behavioral change affects google_compute_backend_service and google_compute_global_forwarding_rule. Their default load-balancing_scheme now shifts from EXTERNAL to EXTERNAL_MANAGED. This means configurations that don't set the field will use the new external Application Load Balancer instead of the Classic one. Teams that depend on Classic behavior must set load_balancing_scheme = "EXTERNAL" explicitly, or a plan may propose changes to existing load balancers.

The release also removes resources and data sources. This is because their backing services have been shut down or replaced. Removed resources include google_iap_brand and google_iap_client (after the IAP OAuth Admin APIs shutdown), the three google_notebooks_* resources (users should move to google_workbench_instance), google_ml_engine_model, and the BeyondCorp app connection, connector, and gateway resources, with Security Gateway resources as the replacement. google_vertex_ai_schedule is replaced by google_colab_schedule. Configurations referencing any of these must be updated before upgrading.

On schema behavior, attributes where ordering carries no meaning have changed from lists to sets. These include fields in Compute Service Attachments, GKE logging and monitoring configuration, and Cloud Security Compliance Frameworks. HashiCorp says this prevents perpetual diffs when an API returns values in a different order than the configuration. Validation is stricter for some Google Cloud APIs. For example, source_contents is now required for google_workflows_workflow. Also, claim_mapping is needed when creating Workforce Identity Pool Provider SCIM tenants. Some state changes, like some integer-to-string conversions, migrate automatically. But others need configuration edits.

The announcement also summarizes 7.x-era capabilities that 8.0 builds on. The provider now supports Terraform list resources. These resources work with the terraform query workflow. You can search for existing infrastructure outside of the state and optionally create resource and import configurations. Coverage spans Compute Engine, IAM, BigQuery, Pub/Sub, Secret Manager, Migration Center, and Network Services. Resource Identity support grew. It now offers providers a clear way to represent a remote object. This can be used for import, along with traditional IDs. Write-only attributes send sensitive values to APIs without saving them. They now include certificate private keys, AlloyDB passwords, and IAP credentials.

The provider is developed jointly by the Google Cloud engineering team, HashiCorp, and the Terraform community, and 8.0 is available in the Terraform Registry. The post does not include benchmarks or adoption figures, and it does not list every removed resource, so the upgrade guide and GitHub changelog are the authoritative references.

A possible upgrade plan could be:

  • Pin the provider and upgrade to the latest 7.x release first. Resolve deprecation warnings, then move to 8.0 in a non-production environment.
  • Search your code for the removed resources listed above, and for load balancer resources that omit load_balancing_scheme. Set it explicitly to avoid unintended migration to EXTERNAL_MANAGED.
  • Check the terraform plan carefully. Focus on resources marked for destroy or replace. Pay special attention to list-to-set conversions and any write-only version attributes that changed type or became required.

Teams running OpenTofu can adopt most of the release, but not all of it. The provider's breaking changes include the EXTERNAL_MANAGED default, removed resources, and list-to-set conversions. These changes are in the provider and apply no matter the CLI. Write-only attributes need OpenTofu 1.11 or later, which is the version that introduced them.

The discovery workflow using Terraform to query and list resources has no equivalent in OpenTofu. A feature request for a tofu query (issue #3787) is still pending. So, those teams will continue using import blocks and generated configuration for their current infrastructure.

OpenTofu's support for Resource Identity was not confirmed at the time of writing, so teams that plan to use identity-based import should check the OpenTofu changelog first. Teams should also verify that the 8.0 provider build is available in the OpenTofu registry before pinning it.

About the Author

Rate this Article

Adoption
Style

BT