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 a user, that user is claiming responsibility for the issue.
- Customers working with a Google Technical Account Manager or Customer Engineer can ask them to reach out internally to expedite investigation and resolution of this issue.
Terraform Version & Provider Version(s)
Terraform v1.15.9
on darwin_arm64
- provider registry.terraform.io/hashicorp/google v8.0.0
Affected Resource(s)
google_container_node_pool
Terraform Configuration
resource "google_container_node_pool" "gpu-node-pool" {
# ...
}
==>
resource "google_container_node_pool" "gpu-node-pool" {
# ...
maintenance_policy {
exclusion_until_end_of_support {
enabled = true
}
}
}
Debug Output
2026-09-01T14:43:24.302+0200 [WARN] Provider "provider[\"registry.terraform.io/hashicorp/google\"].google1" produced an unexpected new value for module.[cluster].google_container_node_pool.gpu-node-pool[0], but we are tolerating it because it is using the legacy plugin SDK.
The following problems may be the cause of any confusing errors from downstream operations:
- .maintenance_policy[0].exclusion_until_end_of_support[0].enabled: was cty.True, but now cty.False
module.[cluster].google_container_node_pool.gpu-node-pool[0]: Modifications complete after 1s [id=projects/[project]/locations/europe-central2/clusters/[cluster]/nodePools/[pool]]
2026-09-01T14:43:24.303+0200 [DEBUG] State storage *remote.State declined to persist a state snapshot
2026-09-01T14:43:24.304+0200 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = error reading from server: EOF"
2026-09-01T14:43:24.307+0200 [INFO] provider: plugin process exited: plugin=.terraform/providers/registry.terraform.io/hashicorp/google/8.0.0/darwin_arm64/terraform-provider-google_v8.0.0_x5 id=40930
2026-09-01T14:43:24.307+0200 [DEBUG] provider: plugin exited
Expected Behavior
Terraform should successfully apply the in-place update to the GKE node pool, enabling the End of Support exclusion by setting enabled = true in the GKE API. If the underlying API does not support updating this specific field in-place, Terraform should return a clear error. Additionally, subsequent terraform plan runs must accurately reflect the actual state of the resource in GCP.
Actual Behavior
Terraform reports a successful apply (Apply complete! Resources: 0 added, 1 changed, 0 destroyed.), but the change is never actually committed to the Google Cloud API.
The exact behavior of subsequent Terraform runs depends entirely on the initial state of the node pool in GCP:
Scenario A (The maintenancePolicy object never existed on the node pool):
Terraform fails to create the object in GCP during an in-place update, but still assumes the operation was successful. It saves the enabled = true configuration to its local .tfstate. Consequently, subsequent terraform plan runs report "No changes. Your infrastructure matches the configuration," even though the API (gcloud) confirms the policy does not exist (state desynchronization).
Scenario B (The maintenancePolicy object was previously created via CLI, but enabled was removed):
Terraform correctly detects the drift during the plan phase (enabled = false -> true). After running apply, Terraform reports success, but the setting is ignored by the GKE API. Because the object itself exists, Terraform's Read function correctly fetches it on the next run, realizes enabled is still missing/false, and proposes the exact same change again. This results in an infinite loop of configuration drift on every subsequent terraform apply.
The feature itself works correctly in GCP, as applying or removing the exclusion via CLI (gcloud) works perfectly.
Steps to reproduce
- Have a working maintenancePolicy added via gcloud:
gcloud container node-pools describe pool-name --cluster cluster-name --region europe-central2 --format="yaml(maintenancePolicy)"
# Result:
# maintenancePolicy:
# exclusionUntilEndOfSupport:
# enabled: true
# endTime: '2027-01-25T00:00:00Z'
# startTime: '2026-09-01T12:19:21.829935034Z'
- Remove the maintenance policy using gcloud:
gcloud container node-pools update pool-name --cluster cluster-name --region europe-central2 --remove-maintenance-exclusion-until-end-of-support
gcloud container node-pools describe pool-name --cluster cluster-name --region europe-central2 --format="yaml(maintenancePolicy)"
# Result:
# maintenancePolicy:
# exclusionUntilEndOfSupport:
# endTime: '2027-01-25T00:00:00Z'
# startTime: '2026-09-01T12:19:21.829935034Z'
- Apply the maintenance policy via Terraform (adding enabled = true):
terraform apply -target=module.cluster_name.google_container_node_pool.gpu-node-pool[0]
# Terraform reports:
# ~ maintenance_policy {
# ~ exclusion_until_end_of_support {
# ~ enabled = false -> true
# }
# }
# Apply complete! Resources: 0 added, 1 changed, 0 destroyed.
- Check the state again via CLI. The configuration was ignored by GCP:
gcloud container node-pools describe pool-name --cluster cluster-name --region europe-central2 --format="yaml(maintenancePolicy)"
# Result (still missing enabled: true):
# maintenancePolicy:
# exclusionUntilEndOfSupport:
# endTime: '2027-01-25T00:00:00Z'
# startTime: '2026-09-01T12:19:21.829935034Z'
- Run terraform plan again.
terraform plan -target=module.cluster_name.google_container_node_pool.gpu-node-pool[0]
# Terraform reports:
# No changes. Your infrastructure matches the configuration.
Important Factoids
The provider is likely omitting this field from the update mask in the PATCH request, causing the GKE API to return HTTP 200 without modifying the setting.
The provider's Read operation fails to refresh the local .tfstate correctly based on the API response, leaving Terraform completely blind to the fact that the resource in GCP lacks the applied setting.
References
GoogleCloudPlatform/magic-modules#17190
020ce19
https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/container_node_pool#nested_exclusion_until_end_of_support
Community Note
Terraform Version & Provider Version(s)
Terraform v1.15.9
on darwin_arm64
Affected Resource(s)
google_container_node_pool
Terraform Configuration
==>
Debug Output
Expected Behavior
Terraform should successfully apply the in-place update to the GKE node pool, enabling the End of Support exclusion by setting
enabled = truein the GKE API. If the underlying API does not support updating this specific field in-place, Terraform should return a clear error. Additionally, subsequentterraform planruns must accurately reflect the actual state of the resource in GCP.Actual Behavior
Terraform reports a successful apply (
Apply complete! Resources: 0 added, 1 changed, 0 destroyed.), but the change is never actually committed to the Google Cloud API.The exact behavior of subsequent Terraform runs depends entirely on the initial state of the node pool in GCP:
Scenario A (The
maintenancePolicyobject never existed on the node pool):Terraform fails to create the object in GCP during an in-place update, but still assumes the operation was successful. It saves the
enabled = trueconfiguration to its local .tfstate. Consequently, subsequentterraform planruns report "No changes. Your infrastructure matches the configuration," even though the API (gcloud) confirms the policy does not exist (state desynchronization).Scenario B (The
maintenancePolicyobject was previously created via CLI, butenabledwas removed):Terraform correctly detects the drift during the plan phase (
enabled = false -> true). After runningapply, Terraform reports success, but the setting is ignored by the GKE API. Because the object itself exists, Terraform's Read function correctly fetches it on the next run, realizesenabledis still missing/false, and proposes the exact same change again. This results in an infinite loop of configuration drift on every subsequentterraform apply.The feature itself works correctly in GCP, as applying or removing the exclusion via CLI (
gcloud) works perfectly.Steps to reproduce
Important Factoids
The provider is likely omitting this field from the update mask in the PATCH request, causing the GKE API to return HTTP 200 without modifying the setting.
The provider's Read operation fails to refresh the local .tfstate correctly based on the API response, leaving Terraform completely blind to the fact that the resource in GCP lacks the applied setting.
References
GoogleCloudPlatform/magic-modules#17190
020ce19
https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/container_node_pool#nested_exclusion_until_end_of_support