-
Notifications
You must be signed in to change notification settings - Fork 28
Default to use --container
param in job submission
#257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
That might be feasible, yet doesn't Also, if this would be a flag, it would apply globally. It is, however, a Snakemake directive per rule, already. Feel free to elaborate, if I misunderstood you! |
Unfortunatelly in my case apptainer is only available on compute nodes - I am not sure why. I personally think that using A qucick fix for me was to use the general-executor-plugin and passing the container to the execution as follow:
The downside is I need to redefine the container in resources, because i couldn't figure out how to reference the value from snakemake pipeline definition. |
@Domomod please apologize: I have written a comment, but apparently did not send it. So, once more:
You might want to find the reason: This does not make sense to me. How is apptainer provided (as a module file? via conda?)? To execute the application, you only need to have it on compute nodes. Yet, to test parameters it apptainer should be available anywhere - on login nodes, too. Be this as it may, are you using containers in every job? Or just specific jobs? If this is a resource per job and not a global catch-all container, why does rule:
...
container:
"<URI or path>"
... not work for you? May we see a workflow definition, parameterization via configs/profiles/the command line and resulting the resulting log? |
Is your feature request related to a problem? Please describe.
I'm facing an issue where singularity/apptainer is not available on login node. Instead my friendly admins aked me to use --container param for sbatch to specify the container.
Describe the solution you'd like
Since --container is a built in of slurm, I would actually expect the plugin to use this when container is specified in rules, and executor is set to slurm.
Describe alternatives you've considered
Another alternative would be to have this behaviour as a optional flag introduced by the plugin.
The text was updated successfully, but these errors were encountered: