Skip to content

Dynamic VM sizing, resource env injection, and job lifecycle controls for GCP Batch#473

Open
ksuderman wants to merge 6 commits into
galaxyproject:masterfrom
ksuderman:gcp-batch-resource-management
Open

Dynamic VM sizing, resource env injection, and job lifecycle controls for GCP Batch#473
ksuderman wants to merge 6 commits into
galaxyproject:masterfrom
ksuderman:gcp-batch-resource-management

Conversation

@ksuderman

Copy link
Copy Markdown
Contributor

PR 3 — Dynamic VM sizing, resource env injection, and job lifecycle controls for GCP Batch

Part of #465.

Summary

Makes the GCP Batch runner size VMs from per-tool resource requests, gives tools the
full VM resources, and adds operational controls for job naming and cleanup. Before
this PR every job used a fixed machine_type, tools ran single-threaded regardless of
the VM, job names could collide, N2/N2D local-SSD counts were rejected, and jobs were
always deleted on cancel (losing Cloud Logging for debugging).

What's included

1. Dynamic VM sizing from cores/mem.
Adds cores and mem fields to GcpJobParams. When either is set,
parse_gcp_job_params() computes an appropriate N2 machine type via a new
compute_machine_type() helper in gcp_util.py (with convert_cpu_to_milli() and
convert_memory_to_mib()), choosing between highcpu/standard/highmem variants.
These helpers are intentionally Galaxy-free so Galaxy's direct
GoogleCloudBatchJobRunner can import them from Pulsar in a follow-up and share one
implementation.

2. Inject GALAXY_SLOTS / GALAXY_MEMORY_MB and set the container compute resource.
On a Batch VM there is no scheduler environment, so $GALAXY_SLOTS fell through to 1
and tools ran single-threaded. When cores/mem are set, these env vars are injected
into the task environment and task.compute_resource is set so the container gets the
full VM instead of Batch's default 2 vCPU / 2 GB.

3. Validate local-SSD count for N2/N2D machine types.
Replaces a bare assert size_gb % 375 == 0 with _validate_ssd_size(), which rounds up
to the nearest 375 GB and adds one more SSD for N2/N2D when the count is odd (these
types require an even count), logging the adjustment instead of crashing.

4. Collision-free job names with a configurable prefix.
Replaces the K8s-style name generator with {prefix}-{job_id}-{unix_timestamp} and
caches it so submit/poll/delete agree. Renames the internal helper
gcp_galaxy_instance_idgcp_job_id_prefix, resolving the prefix as
job_id_prefix > galaxy_instance_id > "pulsar" so jobs from different Galaxy
instances sharing a project are distinguishable.

5. Optional job deletion and AMQP kill().
Both client kill() paths now honor a delete_batch_job destination param (default
true); set false to retain jobs and their Cloud Logging for debugging. Adds the
previously missing kill() to GcpMessageCoexecutionJobClient and wraps deletion in
try/except so a failed delete doesn't cascade.

Files changed

  • pulsar/client/client.py
  • pulsar/client/container_job_config.py
  • pulsar/managers/util/gcp_util.py

Testing

Verified VMs are sized from TPV cores/mem, tools run multi-threaded with the
injected GALAXY_SLOTS, N2 jobs provision with corrected SSD counts, job names no
longer collide, and jobs are retained when delete_batch_job: false. flake8 clean.

Notes

  • Renames the internal gcp_galaxy_instance_id helper to gcp_job_id_prefix; if PR 1
    has merged first this PR may need a trivial rebase. Recommended to merge last of the
    three.
  • Future work (separate PR): update Galaxy's
    galaxy/jobs/runners/util/gcp_batch/helpers.py to re-export the sizing helpers from
    pulsar.managers.util.gcp_util so both runners share one implementation.

ksuderman and others added 6 commits June 16, 2026 21:04
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