[Bug]: managed CPU Ray template has no /mnt hot volume
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
Research direction
Start with managed-workflow-rayjob-cpu.yaml.tmpl and compare it with managed-workflow-rayjob.yaml.tmpl and the managed Job template named in the issue. Trace how the managed CPU Ray template is rendered and run tau run --dry-run=client with compute.gpus: 0 and Ray workers; done means both head and worker pods have tau-hot mounted at /mnt and the three expected environment variables.
Written by the indexing model from the issue text.
Description
Problem
Managed Ray workflows that use no GPUs don't get /mnt at all. managed-workflow-rayjob-cpu.yaml.tmpl has no tau-hot volume or mount and doesn't set TAU_HOT_DIR, TAU_DATASETS_DIR or TAU_CHECKPOINTS_DIR. The GPU managed Ray template (managed-workflow-rayjob.yaml.tmpl) and the managed Job template both mount tau-hot at /mnt and set those variables.
Expected: the CPU managed Ray template provides the same /mnt scratch volume and environment as the GPU template. Code that reads TAU_HOT_DIR then works the same with and without GPUs.
Reproduction
- Write a managed workflow config: set
schema_version, leaveengineunset, and usecompute.gpus: 0with Ray workers. - Run
tau run --dry-run=client. - Neither the head nor the worker pods have a
tau-hotvolume orTAU_HOT_DIR.
TauGrid or tau version
main at bd2b98c2.
Environment
Reproduces with tau run --dry-run=client; no cluster-specific setup needed.
Additional context
This predates #561. That PR renders the profile's hotVolume only for direct engine: job and engine: rayjob configs and leaves the managed templates unchanged. Supporting hotVolume in managed templates would be a separate follow-up.
- Dominant language
- Go
- Stars
- 59
- Forks
- 8
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 84
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Azure/taugrid
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
Similar issues
-
meta
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
last9/last9-mcp-server#554 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
NodeOpUpgrade copies Pod resolv.conf into host OS, causing CoreDNS loops and image-pull failuresOpenarea/operator bug chore
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 86/100
DNSCrypt/dnscrypt-resolvers#1107 ·
-
backend in-progress task
Difficulty 1/5 Under an hour Newbie friendliness 90/100
jphacks/kz_2601#2101 · 1 comment ·
Maintainers usually reply within 1 day