Skip to content

Support for managed job submission to Google Cloud - #64

Open
gregorkrz wants to merge 3 commits into
DeepLearnPhysics:mainfrom
gregorkrz:pr-add-gcloud-support
Open

Support for managed job submission to Google Cloud#64
gregorkrz wants to merge 3 commits into
DeepLearnPhysics:mainfrom
gregorkrz:pr-add-gcloud-support

Conversation

@gregorkrz

@gregorkrz gregorkrz commented Jul 28, 2026

Copy link
Copy Markdown

This PR adds support for --site gcloud to let users submit jobs to thhe Google Cloud Platform. The command pushes the current code to a Google Cloud Storage bucket and executes it in the pimm container, using the machine type specified in the site config.

Gregor Krzmanc and others added 3 commits July 24, 2026 21:52
Add a `gcloud` launch scheduler so `pimm submit` can queue training on
Google Cloud Batch: it provisions a single A100 VM, runs the published
pimm container image, writes artifacts to a gcsfuse-mounted gs:// bucket
(EXP_ROOT is rewritten to the local mount so training code stays
storage-agnostic), and tears the VM down.

- pimm/launch/gcloud.py: Batch job builder + submit driver, gs:// URI
  parsing, optional GCS code staging, job-name sanitization.
- launch/sites/gcloud.yaml: documented gcloud site config.
- config/schema/utils/submit: wire "gcloud" through validation, the
  scheduler enum, and the submit entrypoint.
- tests/unit/test_launch_gcloud.py: unit coverage for the builder.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add a "Managed Google Cloud Batch Submission" section (prerequisites,
`pimm submit --site gcloud` example, and gs:///staging/WANDB notes), list
the site under File Ownership, and note the new `gcloud` scheduler value.
Drop a stale gcloud.yaml comment referencing personal submit scripts.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
finalize_config now falls back to a WANDB_API_KEY=... line in the repo
.env when neither --run.wandb-api-key nor an env-block value is set, so a
gcloud submit authenticates to W&B via EITHER the .env line or the flag
(the flag still wins). The .env file itself is never staged to the VM;
the submit host reads the single key and injects it into the rendered
Batch job env. Update gcloud.yaml, gcloud.py, and launch/README.md to
document both paths.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Comment thread launch/sites/gcloud.yaml
# - A GCS bucket for output, and (for A100) quota in the chosen region.
#
# Fill in every REPLACE_ME_* value below before submitting.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

If we can, please remove a lot of the comments in this code. We can assume the user knows roughly what they're doing, so we don't need to be so overly explanatory.

Comment thread pimm/launch/config.py


def wandb_api_key_from_dotenv(root: Path = ROOT) -> str | None:
"""Read only WANDB_API_KEY from the repo `.env`, ignoring all other vars.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Can this not be pulled in from os.getenv("WANDB_API_KEY")?

This function does not cover when users put their wandb api key in somewhere other than .env, for example their ~.bashrc.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Oh I see you check for that first then look for the dotenv. I think it would be better to just implement complete dotenv loading on import of pimm than have this code like this. That way you just have one line,

wandb_key = run_cfg.get("wandb_api_key") or cfg.get("env", {}).get("WANDB_API_KEY")

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.

2 participants