binder-examples / continuous-build

Show how to use continuous integration to test your dependency specifications
BSD 3-Clause "New" or "Revised" License
8 stars 10 forks source link

[template] needed for Singularity #6

Open vsoch opened 6 years ago

vsoch commented 6 years ago

As discussed in #4 , a Singularity ready template would be desired ! Specifically, this can also build a Docker container, but with intention to import into Singularity. I summarized the issue (and current workaround) in the issue above as follows:

What is needed is a builder template for Singularity that takes these things into account. Possibly creating / using a location with read/write permissions for all?

betatim commented 6 years ago

Don't know much about singularity, so maybe this is a red herring:

By default repo2docker will use the UID and user name of the user that is executing repo2docker to decide where to place the files. So on my laptop things end up in /home/thead with the permissions and ownership setup to match those from the host system. Would this help here? As in is the host user allowed to write to /home/$USER?

vsoch commented 6 years ago

The repo2docker (general) strategy to define a home folder for the user that originally created it makes a lot of sense! However, the continuous builder that we have now sets (artificially) the username in the container to be just "username" - and this is because the end of the line user cannot be predicted (e.g., if I build a container with /home/vanessa it wouldn't correspond with some other user /home/thead ! So we set the username to be username and the files wind up in /home/username. This is again not an issue for Docker - you shell in as root user, you can read/write all-the-things!

Now a bit about Singularity containers - they are (currently) really the only way to bring containers to HPC, which is what is traditionally available on shared cluster resources in academic environments. For Singularity, the /home/username is fine, but given that it's not the user's home, the user of the container doesn't have write permission there. If the notebook is there, they can't edit it. So the fix for a Singularity container could be as simple as changing permissions there for world read/write, or putting the venv and notebooks in a location that is expected to have the correct permissions, or some kind of (less ideal) situation like copying files from there to their actual user home or tmp (in some generated repo2docker folder) so that there is writable. I'm guessing that might have issue for the venv if there are paths written there (I think there are) but it could work with the notebooks. Does this make sense?