Document running Planemo workflows on Slurm clusters (rebase + fixes) - #1683
Document running Planemo workflows on Slurm clusters (rebase + fixes)#1683jmchilton wants to merge 5 commits into
Conversation
| Galaxy can resolve tool dependencies with Conda or run tools in Docker or | ||
| Singularity/Apptainer containers. Containers are generally more reproducible, | ||
| but the available runtime and mount configuration depend on the cluster. The | ||
| examples below use Singularity because it is commonly available on HPC systems. |
There was a problem hiding this comment.
I would probably replace singularity throughout with apptainer.
| Database | ||
| ~~~~~~~~ | ||
|
|
||
| Planemo uses SQLite by default. SQLite is sufficient for small runs, but a |
There was a problem hiding this comment.
This has been fixed, all of the workflow tests also pass on sqlite.
| $ planemo job_config_init \ | ||
| --runner slurm \ | ||
| --singularity \ | ||
| --galaxy_version 25.0 |
There was a problem hiding this comment.
This is awkward, can we assume modern galaxy without the version flag, so that this ages better ?
| --output_json output.json | ||
|
|
||
| Planemo launches a temporary Galaxy instance, runs the workflow, downloads its | ||
| outputs, and records their paths in ``output.json``. |
There was a problem hiding this comment.
After this i would strongly recommend setting up a profile
| Database is locked | ||
| ~~~~~~~~~~~~~~~~~~ | ||
|
|
||
| Errors containing ``sqlite3.OperationalError: database is locked`` usually | ||
| mean the workflow has more concurrent database activity than SQLite can | ||
| comfortably handle. Re-run with PostgreSQL, using either an existing database | ||
| or ``--database_type postgres_singularity``. |
There was a problem hiding this comment.
| Database is locked | |
| ~~~~~~~~~~~~~~~~~~ | |
| Errors containing ``sqlite3.OperationalError: database is locked`` usually | |
| mean the workflow has more concurrent database activity than SQLite can | |
| comfortably handle. Re-run with PostgreSQL, using either an existing database | |
| or ``--database_type postgres_singularity``. |
I don't know how i feel about this, it shouldn't happen anymore. Considering we bootstrap a single galaxy and interact with it i don't really see a need for postgres but that's just my preference for keeping it simple.
| comfortably handle. Re-run with PostgreSQL, using either an existing database | ||
| or ``--database_type postgres_singularity``. | ||
|
|
||
| Galaxy exits during tool installation |
There was a problem hiding this comment.
IIRC @Smeds worked against a cluster with completely broken network. The instructions aren't specific, I would drop that too
| --------------------------------- | ||
|
|
||
| Every bare ``planemo run`` bootstraps Galaxy from scratch: a fresh database, and | ||
| a fresh installation of each tool the workflow needs. On a cluster that is slow, |
There was a problem hiding this comment.
Do we actually keep tools by default ? ... i trust whatever your agent says 😆
8f0c8a1 to
36359f3
Compare
|
Blocking on #1685 now - I think that is the right place to address some of these comments independent of this piece of documentation. |
- Apptainer throughout the prose; the option and the generated keys are still spelled singularity, so say that once rather than silently mixing names. - Recommend a profile right after the first single-server run, and generate the job config into it with profile_job_config_init instead of a loose file. - Drop --galaxy_version 25.0 from both examples; the generator's own default is the modern layout now. - Drop the sqlite-locking rationale, the postgres run example, and the two troubleshooting sections that no longer describe anything reachable. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C5F4LLXH1Rpt2MCLQCgwgU
36359f3 to
c902f16
Compare
|
I could have the agent respond point by point - but I am taking your approve as it is okay that I don't have too 😅. Thanks for the review - I think it really hardened the the final product. |
3 participants
Rebase of #1512 by @Smeds, with both original commits and authorship preserved, plus fixes from review.
The implementation prerequisites discovered during review were fixed in #1685, which has merged. This PR now contains only the Slurm guide in
docs/_running_slurm.rstand its inclusion fromdocs/running.rst.Review feedback from #1512 addressed:
job_config_initfor Slurm and TPVTMPDIRworkaround and documents the defaulttmp_dir: truebehaviorReview feedback from this PR addressed:
singularity, which the guide explainsprofile_job_config_init--galaxy_version 25.0from both examplesTwo comments exposed code defects that were fixed and tested in #1685:
--galaxy_versionselected the legacy 24.2 layout because the Click default pinned 24.2 whilegxjobconfinitdefaults to the modern layout. For--tpv, the legacy output used adynamicrunner, required an externaltpv.yml, and lefttpvdb_slurmas a commented template.profile_job_config_initrecorded the profile's own options JSON asjob_config_file, so the generated Slurm configuration was never applied. It now records the generatedjob_conf.yml.Additional cleanup:
Validation:
tpvdb_slurmdestination,drmaa_library_path,native_specification, andtmp_dirvalues described by the guidegit diff --checkpasses after rebasing onto currentmasterSupersedes #1512.
🤖 Description updated with Codex