Preflight checklist
What problem does this solve?
The Capability Map says "Slurm/cloud-GPU submission … not built yet". That is half right, and the accurate half changes the size of the job.
Detection is built. src/main/compute/compute-service.ts probes for sbatch, qsub, and bsub, exposes detectedScheduler: 'slurm' | 'pbs' | 'lsf' | 'none', and classifies hosts as scheduler_cluster.
Submission is not. src/main/compute/job-dispatcher.ts launches every job the same way regardless of host shape — nohup setsid bash launcher.sh & over SSH — and src/main/compute/job-poller.ts tracks liveness with kill -0 <pid>.
The consequences on a real cluster are immediate: jobs run on the login node instead of the queue, which is the fastest way for a researcher to get their account suspended; no partition, walltime, GPU, or memory request; no queue position; and a hard 7-day ceiling that compute-service.ts already apologizes for in its own error text — "Use a scheduler driver for multi-day jobs."
The code, in other words, already names the missing component.
Proposed solution
Introduce a job driver interface at the existing dispatcher/poller seam — the split is already in the right place.
DirectSshDriver — today's nohup setsid + kill -0 behavior, unchanged, for hosts with no scheduler.SlurmDriver — sbatch for submission, sacct/squeue for status, scancel for cancellation, exit-code and OOM classification from sacct rather than inferred from elapsed time.PbsDriver / LsfDriver — same interface, added as demand appears.
Driver selection follows the detectedScheduler value the probe already returns, with an explicit user override per host, since a cluster may have a scheduler the user still does not want to use.
Scheduler resource requests (partition, walltime, CPUs, memory, GPUs) become part of the host or job configuration. The 7-day cap can then be lifted for scheduler-backed hosts, where the scheduler owns the walltime.
Alternatives considered
- Submit through a generic wrapper script. Loses queue state, cancellation, and accounting — polling would still be blind.
- Ask users to submit manually and register results. Breaks the harvest path that already routes results back into the data-storage location.
Additional context
Also unblocks parameterized sweeps, where per-run scheduler submission is the entire point.
Worth noting for reviewers: harvest-engine.ts and harvest-classifier.ts should need no change — drivers differ in submission and status, not in how results come home.
Part of #917 (preserve-the-backend blend plan). This proposal is additive: it does not change the ACP runtime, artifact/provenance store, notebook execution semantics, or the Prisma schema.
Preflight checklist
What problem does this solve?
The Capability Map says "Slurm/cloud-GPU submission … not built yet". That is half right, and the accurate half changes the size of the job.
Detection is built.
src/main/compute/compute-service.tsprobes forsbatch,qsub, andbsub, exposesdetectedScheduler: 'slurm' | 'pbs' | 'lsf' | 'none', and classifies hosts asscheduler_cluster.Submission is not.
src/main/compute/job-dispatcher.tslaunches every job the same way regardless of host shape —nohup setsid bash launcher.sh &over SSH — andsrc/main/compute/job-poller.tstracks liveness withkill -0 <pid>.The consequences on a real cluster are immediate: jobs run on the login node instead of the queue, which is the fastest way for a researcher to get their account suspended; no partition, walltime, GPU, or memory request; no queue position; and a hard 7-day ceiling that
compute-service.tsalready apologizes for in its own error text — "Use a scheduler driver for multi-day jobs."The code, in other words, already names the missing component.
Proposed solution
Introduce a job driver interface at the existing dispatcher/poller seam — the split is already in the right place.
DirectSshDriver— today'snohup setsid+kill -0behavior, unchanged, for hosts with no scheduler.SlurmDriver—sbatchfor submission,sacct/squeuefor status,scancelfor cancellation, exit-code and OOM classification fromsacctrather than inferred from elapsed time.PbsDriver/LsfDriver— same interface, added as demand appears.Driver selection follows the
detectedSchedulervalue the probe already returns, with an explicit user override per host, since a cluster may have a scheduler the user still does not want to use.Scheduler resource requests (partition, walltime, CPUs, memory, GPUs) become part of the host or job configuration. The 7-day cap can then be lifted for scheduler-backed hosts, where the scheduler owns the walltime.
Alternatives considered
Additional context
Also unblocks parameterized sweeps, where per-run scheduler submission is the entire point.
Worth noting for reviewers:
harvest-engine.tsandharvest-classifier.tsshould need no change — drivers differ in submission and status, not in how results come home.Part of #917 (preserve-the-backend blend plan). This proposal is additive: it does not change the ACP runtime, artifact/provenance store, notebook execution semantics, or the Prisma schema.