set $LMOD_SHORT_TIME to prevent Lmod from creating a user cache

[boegel]

On some systems, Lmod may configured to create a user cache (in ~/.cache/lmod) after a very short amount of time, for example on Vega:

$ ml --config 2>&1 | grep -i LMOD_.*_TIME
User cache valid time(sec) (LMOD_ANCIENT_TIME)                86400
Write cache after (sec) (LMOD_SHORT_TIME)                     2

So if a module command takes longer than 2 seconds, which can happen if CernVM-FS has to pull in an updated Lmod cache first from the EESSI repository, then a user cache will be auto-generated, which (by default) will be considered valid for 24h.

We should prevent that this happens, since it can easily lead to confusion when a module file is available under /cvmfs/software.eessi.io, but it's not visible via module avail (and if Lmod is configured with LMOD_CACHED_LOADS enabled, you won't be able to load it either, despite it being there).

Draft PR, since this script is not the only place we should set $LMOD_SHORT_TIME if we want to take control of this...

[eessi-bot]

Instance eessi-bot-mc-aws is configured to build for:

• architectures: x86_64/generic, x86_64/intel/haswell, x86_64/intel/skylake_avx512, x86_64/amd/zen2, x86_64/amd/zen3, aarch64/generic, aarch64/neoverse_n1, aarch64/neoverse_v1
• repositories: eessi.io-2023.06-compat, eessi-hpc.org-2023.06-software, eessi-hpc.org-2023.06-compat, eessi.io-2023.06-software

[eessi-build-deploy-bot-deucalion]

Instance boegel-bot-deucalion is configured to build for:

• architectures: aarch64/a64fx
• repositories: eessi.io-2023.06-software

[eessi-bot]

Instance eessi-bot-mc-azure is configured to build for:

• architectures: x86_64/amd/zen4
• repositories: eessi-hpc.org-2023.06-software, eessi-hpc.org-2023.06-compat, eessi.io-2023.06-software, eessi.io-2023.06-compat

[ocaisa]

One day is a long time, what if they have their own modules? Can we set this as part of our own cache configuration instead so it is only relevant for us?

[ocaisa]

It seems not to be possible...

[boegel]

The whole point of setting it to 24h is to basically prevent that a user cache can ever be written.

[ocaisa]

But that's a global setting, so it will also never build a cache for modules outside of EESSI

[boegel]

That's true, but i) only when the EESSI environment is set up, ii) that will "only" lead to longer waiting times when running module commands, there's no other negative side effects.

[boegel]

Maybe there's another way to prevent that specific paths (like /cvmfs/software.eessi.io/...) are included in the user cache, not sure.

@rtmclay would know... :)

[ocaisa]

In the EESSI/2023.06 module that we ship, this path is protected:

software-layer/init/modules/EESSI/2023.06.lua

Lines 121 to 124 in 901a944

	if ( mode() ~= "spider" ) then
	prepend_path("MODULEPATH", eessi_module_path)
	eessiDebug("Adding " .. eessi_module_path .. " to MODULEPATH")
	end

so this wouldn't happen with that approach.