feat: allow configurable mode for secondary_boot_disk#2580
Conversation
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>
|
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. |
There was a problem hiding this comment.
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.
Summary
Parameterizes the hardcoded
mode = "CONTAINER_IMAGE_CACHE"in thesecondary_boot_disksdynamic block, exposing a new optionalsecondary_boot_disk_modefield onnode_poolsentries.Why
GKE secondary boot disks support two distinct features that share the same API:
modevalueCONTAINER_IMAGE_CACHEgcfs_config { enabled = true }).The module currently only supports the first variant —
modeis hardcoded since #1946. There is no way for a consumer to use the data-preload variant via this module today.This change makes
modeconfigurable per-pool, while preserving the existing default for backward compatibility.Backward compatibility
Existing consumers using
secondary_boot_diskcontinue to receiveCONTAINER_IMAGE_CACHEautomatically — thelookup()default matches the previous hardcoded value. No tfvars changes required for existing users.Usage
For container image preloading (existing behavior, no change):
For data preloading (new):
Files changed
autogen/main/cluster.tf.tmplandautogen/main/README.mdmake buildandmake docker_generate_docs(perCONTRIBUTING.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.