fix: add missing ForceNew node_config fields to update-variant keepers

[voron]

Summary

The *-update-variant modules use random_id.name keyed off force_node_pool_recreation_resources to roll the node-pool name suffix whenever a ForceNew attribute changes, so create_before_destroy can replace the pool cleanly.

Five module variables that the module already accepts in node_pools map to provider fields declared ForceNew: true but are missing from the keepers list. Changing any of them on an existing pool causes Terraform to plan a replacement against the same node pool name, producing:

Error: googleapi: Error 409: Already exists: projects/<proj>/locations/<region>/clusters/<cluster>/nodePools/<pool>-<suffix>

Reproduced on v41.0.0 and v44.0.0.

Gaps

Module variable	Provider field path
local_nvme_ssd_count	node_config.local_nvme_ssd_block_config.local_ssd_count
threads_per_core	node_config.advanced_machine_features.threads_per_core
enable_nested_virtualization	node_config.advanced_machine_features.enable_nested_virtualization
performance_monitoring_unit	node_config.advanced_machine_features.performance_monitoring_unit
node_affinity	node_config.sole_tenant_config.node_affinity

All five are declared ForceNew: true in hashicorp/terraform-provider-google (google/services/container/node_config.go), and all are already consumed by the module from node_pools.

Fix

Add the five entries to force_node_pool_recreation_resources in autogen/main/cluster.tf.tmpl. make build propagates the change to the three update-variant submodules.

Workaround (until merged)

terraform apply -replace='module.<path>.random_id.name["<pool>"]'

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request adds several ForceNew attributes, such as local_nvme_ssd_count and node_affinity, to the cluster configuration templates and update-variant modules to improve node pool update logic. Feedback suggests including additional missing ForceNew fields, like machine_type and disk_size_gb, to prevent 409 conflicts and ensure reliable zero-downtime updates.

[gemini-code-assist]

The addition of these five fields is correct as they are indeed ForceNew attributes. However, several other critical ForceNew fields that the module accepts in the node_pools map are also missing from this list. Missing these fields will cause the update-variant modules to fail with a 409 conflict when they are changed, as the node pool name won't be rotated, preventing create_before_destroy from working correctly.

Consider adding the following missing fields as well:

• machine_type
• disk_size_gb
• disk_type
• image_type
• node_metadata
• enable_gcfs
• enable_gvnic
• enable_fast_socket
• provisioned_iops
• provisioned_throughput
• enable_confidential_nodes

This will make the zero-downtime update logic much more robust for common node pool configuration changes.

    "local_nvme_ssd_count",
    "threads_per_core",
    "enable_nested_virtualization",
    "performance_monitoring_unit",
    "node_affinity",
    "machine_type",
    "disk_size_gb",
    "disk_type",
    "image_type",
    "node_metadata",
    "enable_gcfs",
    "enable_gvnic",
    "enable_fast_socket",
    "provisioned_iops",
    "provisioned_throughput",
    "enable_confidential_nodes",

[voron]

Thanks, but I don't think these belong in the keepers list — most of them aren't ForceNew in the provider:

• machine_type, disk_size_gb, disk_type, image_type — updateable in place
• enable_gcfs, enable_gvnic, enable_fast_socket — updateable
• provisioned_iops, provisioned_throughput — updateable (handled as part of disk update)
• node_metadata — not a current node_config field (legacy alias of workload_metadata_config.mode, which is updateable)
• enable_confidential_nodes — the ForceNew bits of confidential_nodes are already covered via enable_confidential_storage; the surface this module exposes doesn't add a new ForceNew gap here

Adding any of these would force full pool recreation on routine in-place changes, which is the opposite of what this list is for.

The five fields in this PR were picked by cross-checking node_config in the provider source for ForceNew: true against what the module actually surfaces from node_pools. The reviewers' confidence list in the original write-up enumerated the rest already-covered.

[github-actions]

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days

[voron]

This PR is not stale