Open guma44 opened 4 years ago
I also thought about that in the early stage of development. There are couple of reasons for this.
docker
in runtime
. Caper wants to use the same docker image for all tasks if users want to (--docker
).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.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.
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