Pass through CVMFS config to build container

[ocaisa]

IF a CVMFS configuration exists on the node being used for the build container, it should be used by the container as well

[bedroge]

That's a good idea, and I've actually done that with a similar build container for our local CVMFS-based stack, but you have to be really careful w.r.t. which items you want/can reuse in the container. For instance, at some point I was reusing the proxy that was defined on our compute nodes, but the proxy was only configured for another CVMFS-based project, leading to confusing errors inside the container.

[ocaisa]

Maybe the easiest thing is to just add a flag (which is not set by default) that does this blindly (or bind mounts a custom configuration file)

[trz42]

The eessi_container.sh script could be improved by allowing different ways to specify the target repository:

• just use what is provided in the container image (somewhat implemented by handling --repository EESSI-pilot), e.g., --repository container[:repo_name]
• map what is defined on the host to inside the container (maybe option 3 could be reused), e.g., --repository host[:repo_name] and the script generates a repos.cfg and additional cfg data on the fly OR /etc/cvmfs is simply mapped into the container (for example, if no :repo_name was provided)
• map what is externally provided from the host to inside the container (this is implemented without ext:), e.g., --repository ext[:repo_id] and repo_id is defined in another file repos.cfg