fix: use null comparators in cases where zero or false are meaningful by ItsMattL · Pull Request #2513 · terraform-google-modules/terraform-google-kubernetes-engine

ItsMattL · 2026-01-06T01:08:05Z

As a documented in issues/2304, there are multiple resources where the module incorrectly conflates an undefined field with a defined false or zero value, including advanced_machine_features/enable_nested_virtualization (false vs null), advanced_machine_features/threads_per_core (0 vs null), and queued_provisioning/enabled (false vs null).

In cases where a cluster was first created via the GKE UI, it becomes impossible to later import it into terraform, as the module misinterprets these defaults and tries to force replacement.

Fixes #2304.

…support null values

google-cla · 2026-01-06T01:08:09Z

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 · 2026-01-06T01:08:39Z

Summary of Changes

Hello @ItsMattL, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves a critical GKE cluster import problem by refining how Terraform handles optional fields, ensuring that null values are correctly interpreted as undefined rather than false or zero. This prevents erroneous resource replacement actions when importing existing GKE clusters. Additionally, it includes routine maintenance updates such as advancing copyright years and broadening the compatible version range for the Kubernetes provider.

Highlights

GKE Cluster Import Fix: Modified lookup functions in Terraform configurations across various cluster and node pool definitions to use null as the default value instead of false or 0. This change addresses an issue where Terraform would incorrectly conflate undefined fields with explicit false/zero values, preventing successful import of GKE clusters initially created via the UI by avoiding unintended resource replacement attempts.
Copyright Year Update: The copyright year in numerous metadata.yaml and metadata.display.yaml files throughout the module structure has been updated from 2025 to 2026.
Kubernetes Provider Version Broadening: The version constraint for the Kubernetes provider in modules/workload-identity/metadata.yaml has been updated from ~> 2.13 to a more flexible range of >= 2.10, < 4.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

gemini-code-assist

Code Review

This pull request addresses an issue where false or 0 values for certain GKE node pool attributes were incorrectly treated as unset, leading to problems with Terraform import and state management. The changes modify the logic for queued_provisioning and advanced_machine_features dynamic blocks to correctly differentiate between unset (null) values and explicit false or 0 values. This is achieved by using lookup(..., null) != null checks to determine if an attribute is present in the configuration. The fix is applied consistently across all relevant cluster and node pool resources in the various modules. The changes are correct and effectively resolve the described issue.

apeabody · 2026-01-06T17:44:38Z

/gcbrun

apeabody

Thanks for the contribution @ItsMattL!

From the tests:

Step #63 - "apply node-pool-local": TestNodePool 2026-01-06T18:12:31Z retry.go:99: Returning due to fatal error: FatalError{Underlying: error while running command: exit status 1;
Step #63 - "apply node-pool-local": Error: Missing required argument
Step #63 - "apply node-pool-local":
Step #63 - "apply node-pool-local": with module.example.module.gke.google_container_node_pool.pools["pool-05"],
Step #63 - "apply node-pool-local": on ../../../modules/beta-public-cluster/cluster.tf line 850, in resource "google_container_node_pool" "pools":
Step #63 - "apply node-pool-local": 850: node_config {
Step #63 - "apply node-pool-local":
Step #63 - "apply node-pool-local": The argument "node_config.0.advanced_machine_features.0.threads_per_core" is
Step #63 - "apply node-pool-local": required, but no definition was found.}
Step #63 - "apply node-pool-local": apply.go:34:
Step #63 - "apply node-pool-local": Error Trace: /builder/home/go/pkg/mod/github.com/gruntwork-io/terratest@v0.54.0/modules/terraform/apply.go:34
Step #63 - "apply node-pool-local": /builder/home/go/pkg/mod/github.com/!google!cloud!platform/cloud-foundation-toolkit/infra/blueprint-test@v0.17.9/pkg/tft/terraform.go:571
Step #63 - "apply node-pool-local": /builder/home/go/pkg/mod/github.com/!google!cloud!platform/cloud-foundation-toolkit/infra/blueprint-test@v0.17.9/pkg/tft/terraform.go:630
Step #63 - "apply node-pool-local": /builder/home/go/pkg/mod/github.com/!google!cloud!platform/cloud-foundation-toolkit/infra/blueprint-test@v0.17.9/pkg/tft/terraform.go:669
Step #63 - "apply node-pool-local": /builder/home/go/pkg/mod/github.com/!google!cloud!platform/cloud-foundation-toolkit/infra/blueprint-test@v0.17.9/pkg/utils/stages.go:31
Step #63 - "apply node-pool-local": /builder/home/go/pkg/mod/github.com/!google!cloud!platform/cloud-foundation-toolkit/infra/blueprint-test@v0.17.9/pkg/tft/terraform.go:669
Step #63 - "apply node-pool-local": /workspace/test/integration/node_pool/node_pool_test.go:113
Step #63 - "apply node-pool-local": Error: Received unexpected error:
Step #63 - "apply node-pool-local": FatalError{Underlying: error while running command: exit status 1;
Step #63 - "apply node-pool-local": Error: Missing required argument
Step #63 - "apply node-pool-local":
Step #63 - "apply node-pool-local": with module.example.module.gke.google_container_node_pool.pools["pool-05"],
Step #63 - "apply node-pool-local": on ../../../modules/beta-public-cluster/cluster.tf line 850, in resource "google_container_node_pool" "pools":
Step #63 - "apply node-pool-local": 850: node_config {
Step #63 - "apply node-pool-local":
Step #63 - "apply node-pool-local": The argument "node_config.0.advanced_machine_features.0.threads_per_core" is
Step #63 - "apply node-pool-local": required, but no definition was found.}
Step #63 - "apply node-pool-local": Test: TestNodePool

cwh-hcl · 2026-01-28T13:47:30Z

Pardon my ignorance, do we think this fix will go into the next release?

ItsMattL · 2026-02-02T03:16:55Z

Restored the original default of 0 for threads_per_core.

apeabody · 2026-02-02T22:09:20Z

/gcbrun

cwh-hcl · 2026-02-27T14:28:16Z

Any update on this? Although I'm unfamiliar with the processes of this project I am happy to hop in and try to help get us unstuck if anything I can do from my end :-) @ItsMattL @apeabody

apeabody · 2026-02-27T16:54:24Z

Any update on this? Although I'm unfamiliar with the processes of this project I am happy to hop in and try to help get us unstuck if anything I can do from my end :-) @ItsMattL @apeabody

Re-triggering tests, likely unrelated error

apeabody · 2026-02-27T16:55:03Z

/gcbrun

apeabody · 2026-02-27T16:55:37Z

/gemini review

gemini-code-assist

Code Review

This pull request aims to fix an issue where 0 or false values are incorrectly treated as null (unset), causing issues with Terraform state and resource imports. The changes to the for_each logic in the dynamic blocks are a good step in the right direction. However, the fix is incomplete. In the advanced_machine_features dynamic block, the threads_per_core attribute is still assigned a default value of 0 inside the content block across multiple files. This undermines the change in the for_each and will continue to cause issues when the attribute is not specified. I've left comments on all occurrences of this issue with a suggestion to use null as the default instead, which will fully resolve the problem described.

gemini-code-assist · 2026-02-27T16:58:23Z

autogen/main/cluster.tf.tmpl

-      for_each = lookup(each.value, "threads_per_core", 0) > 0 || lookup(each.value, "enable_nested_virtualization", false) || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
+      for_each = lookup(each.value, "threads_per_core", null) != null || lookup(each.value, "enable_nested_virtualization", null) != null || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
      content {
        threads_per_core             = lookup(each.value, "threads_per_core", 0)


While the for_each condition for the advanced_machine_features dynamic block has been correctly updated to distinguish between an unset value (null) and 0 for threads_per_core, the value assignment within the block still defaults to 0. This can lead to unintended behavior where threads_per_core is set to 0 even when it's not specified in the input, which is the issue this PR aims to fix. To be consistent with the changes and the PR's intent, you should use null as the default value here as well.

threads_per_core = lookup(each.value, "threads_per_core", null)

This is likely still relevant as the content will be used if any of the conditions are not null, so a null default for threads_per_core would be preferable.

This interaction is so confusing even Gemini can't follow it, but I think it's right the way it currently is. The first iteration of this PR set all fields to null. I believe we then discovered that threads_per_core is in fact required to be set if advanced_machine_features is configured, so 48d3d10 followed up and changed it back to zero. In other words:

If no fields are configured (all null), do not set advanced_machine_features.

If any fields are set, set advanced_machine_features plus

If threads_per_core is configured set it to configured

If threads_per_core is unconfigured, set to zero.

The comment in #2513 (review) contains the output stating that

"threads_per_core" is required

gemini-code-assist · 2026-02-27T16:58:23Z

cluster.tf

-      for_each = lookup(each.value, "threads_per_core", 0) > 0 || lookup(each.value, "enable_nested_virtualization", false) || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
+      for_each = lookup(each.value, "threads_per_core", null) != null || lookup(each.value, "enable_nested_virtualization", null) != null || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
      content {
        threads_per_core             = lookup(each.value, "threads_per_core", 0)


This line still defaults threads_per_core to 0. To align with the goal of this PR, which is to differentiate between 0 and an unset value, the default should be null. This prevents Terraform from sending a 0 value when the attribute is not specified.

threads_per_core = lookup(each.value, "threads_per_core", null)

gemini-code-assist · 2026-02-27T16:58:24Z

cluster.tf

-      for_each = lookup(each.value, "threads_per_core", 0) > 0 || lookup(each.value, "enable_nested_virtualization", false) || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
+      for_each = lookup(each.value, "threads_per_core", null) != null || lookup(each.value, "enable_nested_virtualization", null) != null || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
      content {
        threads_per_core             = lookup(each.value, "threads_per_core", 0)


Similar to the other advanced_machine_features block, this line for windows_pools should default threads_per_core to null instead of 0 to correctly handle cases where the value is not specified.

threads_per_core = lookup(each.value, "threads_per_core", null)

gemini-code-assist · 2026-02-27T16:58:24Z

modules/beta-private-cluster-update-variant/cluster.tf

-      for_each = lookup(each.value, "threads_per_core", 0) > 0 || lookup(each.value, "enable_nested_virtualization", false) || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
+      for_each = lookup(each.value, "threads_per_core", null) != null || lookup(each.value, "enable_nested_virtualization", null) != null || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
      content {
        threads_per_core             = lookup(each.value, "threads_per_core", 0)


The for_each logic was updated to handle null vs 0 for threads_per_core, but the assignment within the block still defaults to 0. To complete the fix and align with the PR's intent, this should be changed to default to null.

threads_per_core = lookup(each.value, "threads_per_core", null)

gemini-code-assist · 2026-02-27T16:58:24Z

modules/beta-private-cluster-update-variant/cluster.tf

-      for_each = lookup(each.value, "threads_per_core", 0) > 0 || lookup(each.value, "enable_nested_virtualization", false) || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
+      for_each = lookup(each.value, "threads_per_core", null) != null || lookup(each.value, "enable_nested_virtualization", null) != null || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
      content {
        threads_per_core             = lookup(each.value, "threads_per_core", 0)


The for_each logic was updated to handle null vs 0 for threads_per_core, but the assignment within the block still defaults to 0. To complete the fix and align with the PR's intent, this should be changed to default to null.

threads_per_core = lookup(each.value, "threads_per_core", null)

gemini-code-assist · 2026-02-27T16:58:24Z

modules/beta-public-cluster/cluster.tf

-      for_each = lookup(each.value, "threads_per_core", 0) > 0 || lookup(each.value, "enable_nested_virtualization", false) || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
+      for_each = lookup(each.value, "threads_per_core", null) != null || lookup(each.value, "enable_nested_virtualization", null) != null || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
      content {
        threads_per_core             = lookup(each.value, "threads_per_core", 0)


The for_each logic was updated to handle null vs 0 for threads_per_core, but the assignment within the block still defaults to 0. To complete the fix and align with the PR's intent, this should be changed to default to null.

threads_per_core = lookup(each.value, "threads_per_core", null)

gemini-code-assist · 2026-02-27T16:58:24Z

modules/private-cluster-update-variant/cluster.tf

-      for_each = lookup(each.value, "threads_per_core", 0) > 0 || lookup(each.value, "enable_nested_virtualization", false) || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
+      for_each = lookup(each.value, "threads_per_core", null) != null || lookup(each.value, "enable_nested_virtualization", null) != null || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
      content {
        threads_per_core             = lookup(each.value, "threads_per_core", 0)


The for_each logic was updated to handle null vs 0 for threads_per_core, but the assignment within the block still defaults to 0. To complete the fix and align with the PR's intent, this should be changed to default to null.

threads_per_core = lookup(each.value, "threads_per_core", null)

gemini-code-assist · 2026-02-27T16:58:24Z

modules/private-cluster-update-variant/cluster.tf

-      for_each = lookup(each.value, "threads_per_core", 0) > 0 || lookup(each.value, "enable_nested_virtualization", false) || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
+      for_each = lookup(each.value, "threads_per_core", null) != null || lookup(each.value, "enable_nested_virtualization", null) != null || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
      content {
        threads_per_core             = lookup(each.value, "threads_per_core", 0)


The for_each logic was updated to handle null vs 0 for threads_per_core, but the assignment within the block still defaults to 0. To complete the fix and align with the PR's intent, this should be changed to default to null.

threads_per_core = lookup(each.value, "threads_per_core", null)

gemini-code-assist · 2026-02-27T16:58:24Z

modules/private-cluster/cluster.tf

-      for_each = lookup(each.value, "threads_per_core", 0) > 0 || lookup(each.value, "enable_nested_virtualization", false) || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
+      for_each = lookup(each.value, "threads_per_core", null) != null || lookup(each.value, "enable_nested_virtualization", null) != null || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
      content {
        threads_per_core             = lookup(each.value, "threads_per_core", 0)


The for_each logic was updated to handle null vs 0 for threads_per_core, but the assignment within the block still defaults to 0. To complete the fix and align with the PR's intent, this should be changed to default to null.

threads_per_core = lookup(each.value, "threads_per_core", null)

gemini-code-assist · 2026-02-27T16:58:24Z

modules/private-cluster/cluster.tf

-      for_each = lookup(each.value, "threads_per_core", 0) > 0 || lookup(each.value, "enable_nested_virtualization", false) || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
+      for_each = lookup(each.value, "threads_per_core", null) != null || lookup(each.value, "enable_nested_virtualization", null) != null || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
      content {
        threads_per_core             = lookup(each.value, "threads_per_core", 0)


The for_each logic was updated to handle null vs 0 for threads_per_core, but the assignment within the block still defaults to 0. To complete the fix and align with the PR's intent, this should be changed to default to null.

threads_per_core = lookup(each.value, "threads_per_core", null)

cwh-hcl · 2026-03-03T14:29:48Z

@apeabody @ItsMattL looks like it still failed :( I am unable to view the Cloud Build logs (Project 2843445864) to check the error being referenced. Could a maintainer please grant me Cloud Build Viewer role or perhaps share the logs?

apeabody · 2026-03-03T16:12:25Z

@apeabody @ItsMattL looks like it still failed :( I am unable to view the Cloud Build logs (Project 2843445864) to check the error being referenced. Could a maintainer please grant me Cloud Build Viewer role or perhaps share the logs?

I suspect the error isn't related to the change:

Step #43 - "verify upstream-nameservers-local": TestUpstreamNameservers 2026-02-27T17:32:37Z logger.go:67: Running command kubectl with args [--context gke_ci-gke-06535adc-d560_us-central1_upstream-nameservers-cluster-1wuc get configmap kube-dns -n kube-system -o json --show-managed-fields]
Step #43 - "verify upstream-nameservers-local": TestUpstreamNameservers 2026-02-27T17:32:37Z logger.go:67: error: error loading config file "/builder/home/.kube/config": yaml: line 25: could not find expected ':'
Step #43 - "verify upstream-nameservers-local":     upstream_nameservers_test.go:76: 
Step #43 - "verify upstream-nameservers-local":         	Error Trace:	/workspace/test/integration/upstream_nameservers/upstream_nameservers_test.go:76
Step #43 - "verify upstream-nameservers-local":         	            				/builder/home/go/pkg/mod/github.com/!google!cloud!platform/cloud-foundation-toolkit/infra/blueprint-test@v0.18.0/pkg/tft/terraform.go:745
Step #43 - "verify upstream-nameservers-local":         	            				/builder/home/go/pkg/mod/github.com/!google!cloud!platform/cloud-foundation-toolkit/infra/blueprint-test@v0.18.0/pkg/tft/terraform.go:777
Step #43 - "verify upstream-nameservers-local":         	            				/builder/home/go/pkg/mod/github.com/!google!cloud!platform/cloud-foundation-toolkit/infra/blueprint-test@v0.18.0/pkg/utils/stages.go:31
Step #43 - "verify upstream-nameservers-local":         	            				/builder/home/go/pkg/mod/github.com/!google!cloud!platform/cloud-foundation-toolkit/infra/blueprint-test@v0.18.0/pkg/tft/terraform.go:777
Step #43 - "verify upstream-nameservers-local":         	Error:      	Received unexpected error:
Step #43 - "verify upstream-nameservers-local":         	            	error while running command: exit status 1; error: error loading config file "/builder/home/.kube/config": yaml: line 25: could not find expected ':'
Step #43 - "verify upstream-nameservers-local":         	Test:       	TestUpstreamNameservers
Step #43 - "verify upstream-nameservers-local":     jsonresult.go:43: Error parsing output, invalid json: error: error loading config file "/builder/home/.kube/config": yaml: line 25: could not find expected ':'
Step #43 - "verify upstream-nameservers-local": 2026/02/27 17:32:37 RUN_STAGE env var set to verify
Step #43 - "verify upstream-nameservers-local": 2026/02/27 17:32:37 Skipping stage teardown
Step #43 - "verify upstream-nameservers-local": --- FAIL: TestUpstreamNameservers (237.45s)

apeabody · 2026-03-03T16:12:54Z

/gcbrun

cwh-hcl · 2026-03-05T13:52:07Z

Ugh still failing. From those errors you shared it appears the /builder/home/.kube/config must be getting generated dynamically and incorrectly somehow.

apeabody · 2026-03-05T18:30:17Z

Ugh still failing. From those errors you shared it appears the /builder/home/.kube/config must be getting generated dynamically and incorrectly somehow.

I'll re-run

Step #67 - "verify node-pool-local": TestNodePool 2026-03-03T16:55:15Z command.go:123: Running command gcloud with args [config get-value project --format json]
Step #67 - "verify node-pool-local": TestNodePool 2026-03-03T16:55:16Z command.go:212: "cloud-foundation-cicd"
Step #67 - "verify node-pool-local":     node_pool_test.go:72: 
Step #67 - "verify node-pool-local":         	Error Trace:	/workspace/test/integration/node_pool/node_pool_test.go:72
Step #67 - "verify node-pool-local":         	            				/builder/home/go/pkg/mod/github.com/!google!cloud!platform/cloud-foundation-toolkit/infra/blueprint-test@v0.18.0/pkg/tft/terraform.go:745
Step #67 - "verify node-pool-local":         	            				/builder/home/go/pkg/mod/github.com/!google!cloud!platform/cloud-foundation-toolkit/infra/blueprint-test@v0.18.0/pkg/tft/terraform.go:777
Step #67 - "verify node-pool-local":         	            				/builder/home/go/pkg/mod/github.com/!google!cloud!platform/cloud-foundation-toolkit/infra/blueprint-test@v0.18.0/pkg/utils/stages.go:31
Step #67 - "verify node-pool-local":         	            				/builder/home/go/pkg/mod/github.com/!google!cloud!platform/cloud-foundation-toolkit/infra/blueprint-test@v0.18.0/pkg/tft/terraform.go:777
Step #67 - "verify node-pool-local":         	Error:      	Input ('') needs to be valid json.
Step #67 - "verify node-pool-local":         	            	JSON parsing error: 'unexpected end of JSON input'
Step #67 - "verify node-pool-local":         	Test:       	TestNodePool
Step #67 - "verify node-pool-local":         	Messages:   	has the expected taints

apeabody · 2026-03-05T22:18:24Z

autogen/main/cluster.tf.tmpl

-      for_each = lookup(each.value, "threads_per_core", 0) > 0 || lookup(each.value, "enable_nested_virtualization", false) || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
+      for_each = lookup(each.value, "threads_per_core", null) != null || lookup(each.value, "enable_nested_virtualization", null) != null || lookup(each.value, "performance_monitoring_unit", null) != null ? [1] : []
      content {
        threads_per_core             = lookup(each.value, "threads_per_core", 0)


This is likely still relevant as the content will be used if any of the conditions are not null, so a null default for threads_per_core would be preferable.

modify advanced_machine_features and queued_provisioning dynamics to …

fcfd224

…support null values

ItsMattL requested review from a team, apeabody, ayushmjain, ericyz and q2w as code owners January 6, 2026 01:08

gemini-code-assist bot reviewed Jan 6, 2026

View reviewed changes

Merge branch 'main' into main

36266df

apeabody changed the title ~~use null comparators in cases where zero or false are meaningful~~ fix: use null comparators in cases where zero or false are meaningful Jan 6, 2026

apeabody requested changes Jan 6, 2026

View reviewed changes

default threads_per_core to 0

48d3d10

ItsMattL requested a review from krprabhat-eng as a code owner February 2, 2026 03:14

Merge branch 'main' into main

db16403

Merge branch 'main' into main

fcbc819

gemini-code-assist bot reviewed Feb 27, 2026

View reviewed changes

Merge branch 'main' into main

75f5038

apeabody requested changes Mar 5, 2026

View reviewed changes

cwh-hcl mentioned this pull request Mar 9, 2026

advanced_machine_features and queued_provisioning forces replacement of node pool created through UI #2304

Open

ItsMattL requested a review from apeabody March 25, 2026 22:06

Conversation

ItsMattL commented Jan 6, 2026

Uh oh!

google-cla bot commented Jan 6, 2026

Uh oh!

gemini-code-assist bot commented Jan 6, 2026

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

apeabody commented Jan 6, 2026

Uh oh!

apeabody left a comment

Choose a reason for hiding this comment

Uh oh!

cwh-hcl commented Jan 28, 2026

Uh oh!

ItsMattL commented Feb 2, 2026

Uh oh!

apeabody commented Feb 2, 2026

Uh oh!

cwh-hcl commented Feb 27, 2026

Uh oh!

apeabody commented Feb 27, 2026

Uh oh!

apeabody commented Feb 27, 2026

Uh oh!

apeabody commented Feb 27, 2026

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

apeabody Mar 5, 2026

Choose a reason for hiding this comment

Uh oh!

ItsMattL Mar 12, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

cwh-hcl commented Mar 3, 2026

Uh oh!

apeabody commented Mar 3, 2026

Uh oh!

apeabody commented Mar 3, 2026

Uh oh!

cwh-hcl commented Mar 5, 2026