From the mattermost chat: clarify the volume mounts/shared directories

[katilp]

Reading through the mattermost chat, in addition to the quick comments in #19 the volume mounts/shared directories seemed to be the biggest source of confusion:

We have several different example commands mounting volumes or sharing local directories.

There are several use cases:

• X11 .Xauthority mount
• ssh key mount
• /cvmfs mount
• local directory/volume mount for file transfer

These are quite well explained in @caredg 's reply:

A line like this should work: docker run --name odcvmfsvol -it --net=host --env="DISPLAY" --volume="$HOME/.Xauthority:/root/.Xauthority:rw" --volume="/home/ecarrera/.ssh:/home/cmsusr/.ssh" -v "/home/ecarrera/playground:/playground" -v "/cvmfs:/cvmfs:shared" cmsopendata/cmssw_5_3_32 /bin/bash Here i mount 4 things:

• My .Xauthority volume for opening graphical windows in the container
• My .ssh directory (this is not really necessary but makes it easier to work with Git if you are developing things but can be ommitted
• My personal folder at /home/ecarrera/playground which I mount on /playground in the container. Note that I do not mount it in any area of the container that has already content, like Kevin mentioned.
• I mount the /cvmfs directory where the cvmfs client, after you install it, will expand the shared areas from CERN

(Note however, w.r.t the 3rd item above, for a pull and push from and to git, the shared area could be the container home where 1) the CMSSW_5_3_32/src is built in the container at the start, 2) which then has CMSSW_5_3_32/src visible on the local host, to which a repository can be pulled/cloned from git (on the local host) 3) in which the code can be compiled and run in the container, 4) from which updates can be pushed from the local host. This worked in WSL linux, but not sure if the share setting are the same e.g. on MacOS. I think @mattbellis had a look on that (maybe on linux?). However, we should avoid instructing anything (beyond the strict necessity) which is very much dependent on the local host settings, or then do the proper work to divide the instructions in separate local OS tabs as often done.)

Furthermore, there's much confusion for mounting cvmfs in the container, and I cannot recall why anyone would need to do it (probably because mounting it locally did not work?)

We should work towards a solution where the local cvmfs installation and /cvmfs mount would not be necessary. For the moment, it is needed:

• if we instruct reading GT from /cvmfs (as for the VM and as in http://opendata.cern.ch/docs/cms-guide-for-condition-database)
  • however, the OD containers can read GT from the frontier servers so in the medium term, cvmfs mount is not needed for that
  • however2, we should find a better light-weight solution for the condition data, it does not make sense to download several GBs to read just a few text files
• if we instruct installing brilcalc through cvmfs
  • this could be avoided if brilcalc and all it needs would be put in a separate container @tpmccauley is looking at that

[katilp]

@caredg @mattbellis @clelange We could have a chat on this at a certain point and see how to best unify the instructions in a longer term.

[caredg]

I noticed that in the VM we set up the release from cvmfs but on the container the release lives within the image already (if I am not mistaken). A temporary unification would be to, as Kevin had been pushing for, build a docker image with the cvmfs client already in it. That way we can pull the release and the conditions from cvmfs (and maybe optimize the conditions read-in as well later). What I am a little afraid of is to allow (or encourage) direct read from the database (I can foresee someone complaining harshly about that in the future) ..... I hope I know what I am talking about though (I should definitely learn how to build docker images so I can be of actual help)

[clelange]

I noticed that in the VM we set up the release from cvmfs but on the container the release lives within the image already (if I am not mistaken). A temporary unification would be to, as Kevin had been pushing for, build a docker image with the cvmfs client already in it. That way we can pull the release and the conditions from cvmfs (and maybe optimize the conditions read-in as well later). What I am a little afraid of is to allow (or encourage) direct read from the database (I can foresee someone complaining harshly about that in the future) ..... I hope I know what I am talking about though (I should definitely learn how to build docker images so I can be of actual help)

We have that image already (since years), and we can advertise it. Mind, however, that this does not work with SLC5.

[caredg]

Closing, as most of this was already addressed in newer version, I think