Adding non-standard ways to use EESSI

[hvelab]

As per this issue: https://gitlab.com/eessi/support/-/issues/119

First batch regarding the cvmfsexec usage. A couple of thoughts:

• Should we add the cvmfsexec_eessi.sh and the orted wrapper in some repo so people can directly clone and not have to copy-paste it?
• Worked fine in my local Ubuntu 22.04 and a remote Rocky Linux test environment,. For some colleagues I asked to test in their locals (Ubuntu 23), this error msg occured:

 $ ./test.sh ls /cvmfs/software.essi.io
/tmp/rzarco/tmp.sdsrKCrQH7/cvmfsexec/dist should be rpm2cpio of cvmfs rpm
mountrepo software.eessi.io failed

so seems only works for RHEL :/

[ocaisa]

cvmfsexec only works for RHEL-like systems 😢

[hvelab]

cvmfsexec only works for RHEL-like systems 😢

True, in my Ubuntu works but seems that its because I have CVMFS already available, I tested it in other systems without CVMFS and the same error message shows :(

[ocaisa]

Does this work? I imagine that you need to load the modules you need in your cvmfsexec_eessi.sh script or it will not find orted inside the container

[casparvl]

I think the reason this works is that the context calling the orted command already has the module loaded, isn't it? I.e. the typical usage is:

module load EESSI/2023.06
module load GROMACS/whatever
# This mpirun calls `orted` on the remote node, probably exporting the _current_ `$PATH`, on which `orted` is available because the mpi module is loaded through GROMACS. It would fail if we _don't_ wrap that `orted` command in a `~/bin/cvmfsexec_eessi.sh`, because on the remote node the CVMFS repo is _not_ yet mounted. However, mounting the CVMFS repo is _sufficient_, because the `$PATH` is correct - it just points to the CVMFS repo...
mpirun <something>

[casparvl]

Note that this comes directly from https://www.eessi.io/docs/blog/2024/06/28/espresso-portable-test-run-eurohpc/ , so we know this worked when we did this on Deucalion :)

[ocaisa]

Should link to the CVMFS docs on this early on.

[ocaisa]

cvmfs-2.13.0 was released a few minutes ago, so the approach with shrinkwrap should work out-of-the-box if you have that version available. This also means I can start working on a script to manage this once our client containers are updated

[casparvl]

This section should probably start by saying that it requires a system that does have access to the repository. Note that running this from the EESSI container is probably also an option (in fact, I think I did that once...), but it might be worth explaining that separately not to confuse people (doing it on a node that has CVMFS natively is definitely easier).

[casparvl]

Suggested change

	In addition, you need to create a spec file `software.eessi.io.spec` with the files you want to include and/or exclude in the shrinkwrap. Contents are:
	In addition, you need to create a spec file `software.eessi.io.spec` with the files you want to include and/or exclude in the shrinkwrap. For example:

[casparvl]

I think the spec file requires extra explanation. E.g. we should probably state that the compat layer is always needed, as is the dir that allows initializing the environment. Then, we should probably give some examples: e.g. how to export the full x86_64 tree (with the warning that it requires a massive amount of memory due to a known issue, see https://gitlab.com/eessi/support/-/issues/118), how to export for a single (or a handful) of micro-architectures, and maybe even an approach how to export for a single piece of software (i.e. load the GROMACS module, check all EBROOT variables, and export those - that should be enough...)

[casparvl]

Maybe we should also make clear that other compression tools can be used. E.g. zstd is typically much faster (because it is multithreaded) than the standard gzip. It also typically achieves better compression.

mksquashfs /tmp/cvmfs software.eessi.io.sqsh -comp zstd