[idea] Make passing environment variables and mounting $HOME optional and off by default #445
Milestone
Comments
|
+1. The passing of env variables has made debugging of containers on TACC quite challenging for me. |
|
+1 again @chrisfilo - I think we could think of a good way to include this in our refactor to add an |
|
I think this should be handled by a command line flag rather than an image description file so users using images converted directly from Docke Hub could benefit from it. |
|
yes the underlying functionality would be accessible in multiple ways, only one of them being the spec file. |
|
Without thinking too deeply on the proposal itself -- I think it's a bit dangerous to break backward compatibility for existing sites / containers. While this is a trip hazard for new users, it's worth noting that existing users have already tripped, fallen, and written a workaround to get back up. Let's not break the workaround! What does make sense to me is:
|
|
Well, I can easily answer both requests with usage tips and tell me if anyone sees a better way to implement: This will change the contents/location of the home directory to whatever you have inside of the directory $ singularity shell -H ~/virtualized_home container.imgThis will run Singularity in a clean environment with no unnecessary variables: $ env -i singularity shell container.imgAnd if you combine the two, I think you will have exactly what you need. But... Let me know if you think there is a better way to implement either of these or if I misunderstood and it doesn't suitably handle your needs. |
|
@bbockelm I liek the idea of specifying how home mount and environemnt variables are handled to be done in the container image. Having said that for images imported from Docker Hub I would make ignoring host ENV and HOME a default that can be changed on the command line. @gmkurtzer the |
|
What is in hrmm... It does seem that the your dot files are still being found, interesting. Can you send the |
|
Could it have something to do with the fact that sherlock automatically mounts scratch directories? also these might be relevant: |
|
Yes, there could be something weird going on there actually... @chrisfilo, can you create a new empty directory in |
|
|
Good call @vsoch, check out this debugging line: |
|
Any more thoughts on the topic? I really think that if we do not change the defaults we will have a lot of confused users (especially in context of PYTHOPATH env var). I strongly vote for making the passing of the environment variables and mounting $HOME optional and OFF by default. It will save us a lot of headaches with user support. |
|
Changing semantics and behaviors for existing workflows is bad, bad, bad. Users hate that more than confusing semantics in the first place. For example, only changing the default would break the HTCondor integration. I'd prefer to go the direction outlined above - change the default for new users but keep existing containers' behavior. |
|
I agree with @bbockelm, we can't change existing precedent, but this is a great idea. We have the $ singularity shell -e /tmp/centos.img
Singularity: Invoking an interactive shell within container...
Singularity centos.img> export
declare -x LD_LIBRARY_PATH=":/usr/local/lib:/usr/local/lib64"
declare -x LS_COLORS=""
declare -x OLDPWD
declare -x PATH="/usr/local/bin:/usr/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin"
declare -x PS1="Singularity centos.img> "
declare -x PWD="/home/gmk/git/singularity"
declare -x SHLVL="1"
declare -x SINGULARITY_CONTAINER="centos.img"
declare -x SINGULARITY_INIT="1"
declare -x SINGULARITY_NAME="centos.img"
Singularity centos.img> exitNote: The new Note2: This feature is implemented in the C part of the execution path, which means that any envars set in |
gmkurtzer
added a commit
that referenced
this issue
Mar 20, 2017
wpoely86
added a commit
to wpoely86/singularity
that referenced
this issue
Mar 20, 2017
* origin/development: (67 commits) Clean environment when using -C/--containall flags Add -e/--cleanenv runtime action option (ref: apptainer#445) Moved test Cleaned up tests and added more docker tests Fix shell debug/verbose messages to goto STDERR (ref apptainer#481) fix: removed tabs fix: removed driver if added test fix syntax Testing a wider print format Minor fix for CI Clean redundant messages of label additions Support optional tests Make container writable for removal test Added config ownership test Fix comments and empty lines in the %file sections (and add tests) Finishing up the new test code Fixes for runscript and environment overriding what is in the sections and python Test updates... WIP Fix %labels parsing during bootstrap ...
|
Excited about the |
|
Between the Thanks everyone! |
|
In my case, The solution was either or
|
|
@hisplan This is a very good point and additionally I want to mention that in the 2.3 development branch you can also use the Thanks! |
|
vs. |
|
In that case, the use of Also, I stress, that not all versions of Sorry about being a nag about shell pedantics, but I've already seen this mistake bite others. Hope that helps! |
|
By the way, it appears that the I appreciate all the hard work you guys put into this! |
|
Done! But will I remember for future issues? Hopefully, but I may need reminding. ;) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The main advantage of using singularity is providing reproducible software environment that is independent of the host machine. However, many new users of singularity stumble into problems with host environment being mixed up with the software inside the container. This is caused by two issues:
Both of those features can be useful if user want to mix software from the host with software inside the container, but they cause a lot of troubles to new users. Therefore I would propose making them optional (from a perspective of a non-root end user - in a form of command line flag) and disable them by default.
The text was updated successfully, but these errors were encountered: