Allow different overrides for compat (i.e. CPU family) and modules (i.e. SOFTWARE_SUBDIR)#222
Open
casparvl wants to merge 1 commit intoEESSI:mainfrom
Open
Conversation
…useful for e.g. running the test suite on an x86_64-based login node, when targetting RISCV-based batch nodes. The reason is that the test suite generates tests based on the available modules, so on the login node (where the reframe runtime runs), we want to see the RISCV modules. This changes allows that when someone does 'EESSI_CPU_FAMILY_OVERRIDE=x86_64 EESSI_VERSION_OVERRIDE=2025.06-001 EESSI_SOFTWARE_SUBDIR_OVERRIDE=riscv64/generic module load EESSI/2025.06'
Member
|
I was wondering how I had danced around this in my API PR: https://github.com/EESSI/api_data/pull/16/files#diff-9cf2000c53760d837a449f874e53f792819108d3a4bf346336d0f7d082deae2cR73-R78 |
Member
|
Looks good, can you just confirm that things still work fine without the override set (just in case). |
Contributor
Author
|
Good point, let me double check :D |
Member
|
Now that I think about it, we should add CI for this as we do for many of the other and a test would be something like |
Contributor
Author
|
Works However, I do see this when I'm using the override and then unloading: I'm not quite sure why. Seems to come from here but... that's an LmodError, and here it's printed as a warning - that seems odd. I also don't really understand what's different on unload here that this suddenly produces this error. |
Contributor
Author
Works fine. Makes sense: without the overrides, it has no idea it should look for the |
Contributor
Author
|
Ok, so all is looking fine then. I'll built it, if you're ok with it as well, you can deploy @ocaisa |
Contributor
Author
|
bot: build repo:eessi.io-2023.06-software instance:eessi-bot-mc-aws for:arch=x86_64/amd/zen2 |
|
New job on instance
|
|
New job on instance
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This faciliates e.g. checking of the available RISCV modules on an X86_64 host.
This is useful for e.g. running the test suite on an x86_64-based login node, when targetting RISCV-based batch nodes. The reason is that the test suite generates tests based on the available modules, so on the login node (where the reframe runtime runs), we want to see the RISCV modules.
This change allows doing
on an X86_64-based host, and make the RISC-V module stack available:
Admittedly, the usage is a bit restricted since this is really only useful if module stacks are NOT in sync and if the CPU family for the target of interest is different from the one on the host. Then again, it is an override: nothing changes in the default behavior, and you don't set it unless you have very good reasons to. It simply allows us extra flexibility when testing things.
Issue came up in EESSI/dev.eessi.io-riscv#34 (comment) when trying to set up period tests on the RISC-V cluster.