[ishitachail]

This PR standardizes the GKE H4D blueprint to support unified consumption options:

1. Option 1: Specific Reservation (default)
2. Option 2: DWS Flex Start
3. Option 3: DWS Flex Start + Queued Provisioning
4. Option 4: Spot
5. Option 5: On-Demand

Compact Placement Across Consumption Models

Compact placement is configured directly under Options 1, 4, and 5 (placement_policy: { type: COMPACT }) in gke-h4d-deployment.yaml:

• Static Node Pools (Options 1, 4, 5): H4D instances leverage the Falcon IRDMA interconnect for HPC workloads, where compact physical co-location within the same network topology is default/expected behavior. Standard GCE group placement policies work natively on static node pools.
• Dynamic Autoscaling Pools (Options 2 & 3 - DWS Flex Start and Queued Provisioning): GCE group placement policies cannot be directly configured on node pools managed by DWS Flex Start or Queued Provisioning. Therefore, placement_policy is left unconfigured (null) for Options 2 and 3 in the deployment template.

Note on Compact Placement for Flex Start: To achieve compact placement with DWS Flex Start, a Compute Engine Workload Policy (HIGH_THROUGHPUT) must be defined and attached to the workload. A link to the documentation explaining how to configure workload policies for compact placement with DWS Flex Start will be added in a follow-up PR once the documentation is ready.

Workload Execution & DWS Flex Start Test Job

• Ported the sample batch test job (test-job-flex.yaml) from gke-consumption-options to examples/gke-h4d/. The job defines matching node selectors (cloud.google.com/gke-flex-start: "true") and tolerations (node-type=h4d:NoSchedule) required to trigger GKE Cluster Autoscaler scale-up from 0.
• Updated examples/gke-h4d/README.md with complete prerequisites, deployment instructions, step-by-step lifecycle monitoring for DWS scale-up/scale-down, and a clarification note that the Kubeflow MPI Operator requires static node pools (Options 1, 4, or 5).

Cloud Build Daily Test Cleanup

• Refactored gke-h4d-onspot.yaml build definition to eliminate fragile sed blueprint replacements. It now leverages the native blueprint variables and safely overrides remote-node parameters.

---

Submission Checklist

NOTE: Community submissions can take up to 2 weeks to be reviewed.

Please take the following actions before submitting this pull request.

• Fork your PR branch from the Toolkit "develop" branch (not main)
• Test all changes with pre-commit in a local branch #
• Confirm that "make tests" passes all tests
• Add or modify unit tests to cover code changes
• Ensure that unit test coverage remains above 80%
• Update all applicable documentation
• Follow Cluster Toolkit Contribution guidelines #

[gemini-code-assist]

Summary of Changes

Hello, 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 updates the GKE H4D blueprint to provide a flexible and unified approach to resource consumption. By standardizing configuration across different node pool types, it simplifies the deployment process for various HPC workload requirements while ensuring compatibility with GKE's native autoscaling and placement policies.

Highlights

• Unified Consumption Models: Standardized the GKE H4D blueprint to support five distinct consumption options, including Specific Reservation, DWS Flex Start, DWS Flex Start with Queued Provisioning, Spot, and On-Demand.
• DWS Flex Start Integration: Added support for dynamic autoscaling pools using DWS Flex Start, including a sample test job and detailed documentation for lifecycle monitoring and workload requirements.
• Build Process Refactoring: Improved the Cloud Build daily test cleanup by replacing fragile 'sed' commands with native blueprint variable overrides for more robust testing.

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 the 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 counterproductive. 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.

Footnotes

1. 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 updates the GKE H4D blueprint to support multiple consumption models, such as Specific Reservation, DWS Flex Start, Spot, and On-Demand, and introduces a sample batch job for testing DWS Flex Start. The README has been extensively updated with detailed setup, execution, and cleanup instructions. Review feedback suggests removing the 'git checkout main' step from the README to prevent users from switching away from their current branch, and adding a clarifying note that Option 1 requires manually configuring the reservation name and static node count to avoid deployment failures.