Skip to content

feat: allow configurable mode for secondary_boot_disk#2580

Open
bbensky wants to merge 1 commit into
terraform-google-modules:mainfrom
bbensky:parameterize-secondary-boot-disk-mode
Open

feat: allow configurable mode for secondary_boot_disk#2580
bbensky wants to merge 1 commit into
terraform-google-modules:mainfrom
bbensky:parameterize-secondary-boot-disk-mode

Conversation

@bbensky
Copy link
Copy Markdown

@bbensky bbensky commented Apr 28, 2026

Summary

Parameterizes the hardcoded mode = "CONTAINER_IMAGE_CACHE" in the secondary_boot_disks dynamic block, exposing a new optional secondary_boot_disk_mode field on node_pools entries.

Why

GKE secondary boot disks support two distinct features that share the same API:

mode value Use case
CONTAINER_IMAGE_CACHE Preloads container images for faster pod start. Requires Image Streaming (gcfs_config { enabled = true }).
(mode omitted) Preloads arbitrary data onto a node-local disk for pods to mount via hostPath.

The module currently only supports the first variant — mode is hardcoded since #1946. There is no way for a consumer to use the data-preload variant via this module today.

This change makes mode configurable per-pool, while preserving the existing default for backward compatibility.

Backward compatibility

Existing consumers using secondary_boot_disk continue to receive CONTAINER_IMAGE_CACHE automatically — the lookup() default matches the previous hardcoded value. No tfvars changes required for existing users.

Usage

For container image preloading (existing behavior, no change):

node_pools = [{
  name                = "my-pool"
  secondary_boot_disk = "projects/my-project/global/images/my-cached-image"
  # secondary_boot_disk_mode defaults to "CONTAINER_IMAGE_CACHE"
}]

For data preloading (new):

node_pools = [{
  name                     = "my-pool"
  secondary_boot_disk      = "projects/my-project/global/images/my-data-image"
  secondary_boot_disk_mode = null   # omits the mode field — data preload
}]

Files changed

  • Source of truth: autogen/main/cluster.tf.tmpl and autogen/main/README.md
  • Regenerated via make build and make docker_generate_docs (per CONTRIBUTING.md)

Tests

This is a small behavioral change with a backward-compatible default. I haven't added an integration test (would require a GCP project I can't easily provision); happy to add one if the maintainers prefer — pointers to the closest existing test welcome.

Parameterize the previously-hardcoded `mode = "CONTAINER_IMAGE_CACHE"`
in the secondary_boot_disks dynamic block via a new optional
`secondary_boot_disk_mode` field on node pools.

This unlocks the data-preload variant of GKE secondary boot disks
(used to mount node-local datasets for hostPath consumption) which
previously could not be expressed via this module.

Default value preserves existing behavior — pools that don't set
secondary_boot_disk_mode continue to receive CONTAINER_IMAGE_CACHE.
Set to null to omit the field for data preloading.

Signed-off-by: Brian Bensky <brianbensky@gmail.com>
@google-cla
Copy link
Copy Markdown

google-cla Bot commented Apr 28, 2026

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.

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces the secondary_boot_disk_mode parameter for GKE node pools across various modules and the main cluster configuration. The changes update the secondary_boot_disk block to dynamically look up the disk mode, defaulting to CONTAINER_IMAGE_CACHE while allowing users to override it or set it to null for data preloading. Documentation in the README files has been updated accordingly to reflect this new optional parameter. I have no feedback to provide as there were no review comments to assess.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant