Singularity backend

[guma44]

Hi,

Is there any particular reason to use singularity runtime attributes as opposed to submit-docker as in Cromwell docs (https://cromwell.readthedocs.io/en/stable/tutorials/Containers/)? I am asking because I am developing workflows and I am wandering which is the way to go and why. What would happen if I have different images in tasks?

Best,
Rafal

[leepc12]

I also thought about that in the early stage of development. There are couple of reasons for this.

• Caper is actually not designed for WDLs in which tasks have their own docker in runtime. Caper wants to use the same docker image for all tasks if users want to (--docker).
• Caper uses the same backend (e.g. Local, slurm, sge) for Singularlity/Docker/No-container. Cromwell only falls back to use submit-docker when docker is defined in runtime. So if we want to use submit-docker for Singularity then that means docker attribute should be shared by both Singularity and Docker. So there should be additional attribute like use_singularity_instead_of_docker. Singularity can bind cromwell's execution directory outside of the container keeping its full path.

[guma44]

Hi,
Thanks a lot for answer. I see it is kind of a design decision. I also think it has some advantages given dependency management in Cromwell is pain in the neck. For systems like HPC only singularity is allowed and submit-docker anyway would use singularity always. Should it be decided by the backend which container technology to use? Assuming people always have only one choice: docker on AWS and singularity on HPC - nothing in between.