checklist for 2021.06 pilot

[boegel]

• define 2021.06 set (PRs: Define 2021.06 set + version bump rdma-core gentoo-overlay#40 + Add ebuild for ReFrame and add it to EESSI set gentoo-overlay#41)
• update Prefix bootstrap snapshot + script (PR: Updates for pilot 2021.06 #109)
• use new build container (PR: Automatically build and publish the container image for bootstrapping Gentoo Prefix #98)
• switch to git rather than rsync for emerge --sync (issue: Use git instead of rsync for gentoo repo #100, PR: Use git instead of rsync for the Gentoo overlay #106)
• fix timezone issue (/etc/localtime is missing in 2021.03 compat layer #93)
• tweak trusted glibc dirs (cfr. Enabling end-user GPU support and ABI-compatible overrides software-layer#108)
• add test step to playbook (PR: Run the ReFrame tests at the end of the playbook #108)
• generate env file for glibc (issue: Installation playbook should make a portage env file for glibc #104, PR: Create glibc env file #107)
• build compat layer for:
  • aarch64
  • ppc64le
  • x86_64
• update CI (.github/workflows/pilot_repo.yml )

[ocaisa]

Can we consider EESSI/software-layer#108 for inclusion here. The repercussions for the compatibility layer would be a change in the trusted glibc dirs (to, for example, /cvmfs/pilot.eessi-hpc.org/host_injections/2021.06/compat/linux/x86_64/lib where /cvmfs/pilot.eessi-hpc.org/host_injections is a variable symlink in CVMFS).

[boegel]

I think it's worth looking into that, yes, added it to the list.
@bedroge Is this something you can look into?

[bedroge]

@boegel Sure, I'll try to take a look at it.

@ocaisa just to make sure that I get it: the only required change in the Ansible playbook that installs the compatibility layer is that it should use user-defined-trusted-dirs=/cvmfs/pilot.eessi-hpc.org/host_injections (instead of the old one /opt/eessi/lib)? And then the repo should get a variant symlink that will point that dir by default to /opt/eessi, but can be overridden using something like $EESSI_HOST_INJECTIONS_PATH?

[ocaisa]

@bedroge Not quite. The trusted dir would be a moving target depending on the pilot release (plus system characteristics), so

user-defined-trusted-dirs=/cvmfs/pilot.eessi-hpc.org/host_injections/$EESSI_PILOT_VERSION/compat/$EESSI_OS_TYPE/$EESSI_CPU_FAMILY/lib

The idea is that the CVMFS variant symlink is for /cvmfs/pilot.eessi-hpc.org/host_injections and that we would then have a tool that would correctly populate (and test) the trusted dir. This would allow us to catch, for example, whether CUDA drivers are new enough for our shipped CUDA stack.

I made a PR for it in #102

[bedroge]

I do see what you're after, but I'm not sure If I get the details / if that's possible. Why do we need the variant symlink for /cvmfs/pilot.eessi-hpc.org/host_injections, and how does that have subdirs if it's a (variant) symlink? Shouldn't the whole thing /cvmfs/pilot.eessi-hpc.org/host_injections/$EESSI_PILOT_VERSION/compat/$EESSI_OS_TYPE/$EESSI_CPU_FAMILY/lib be a (variant) symlink that a user/admin can override to a local directory?

[ocaisa]

The subdirectory structure $EESSI_PILOT_VERSION/compat/$EESSI_OS_TYPE/$EESSI_CPU_FAMILY/lib is created by the script on the host system in a directory that is controlled by whomever controls the CVMFS config. The variant symlink just points to the dir that will contain that structure.

[bedroge]

I get it now, brilliant idea! :-)