More consistent platform priority #1302
Conversation
This fixes an inconsistency observed in GRID jobs when loading a software package "A". The bug was: - The GRID runtime determines available platforms (say el8 and el7) for package A - then launches an el8 apptainer container - alienv executed inside el8 container loads el7 software, inconsistent with the choice of el8 container ... and despite the fact that el8 software A is actually available. Bug fixed by slightly adjusting the platform priority: We always search the current platform first of all before going elsewhere.
|
Goes back to an observation made in ticket https://its.cern.ch/jira/browse/O2-4804. |
|
yes , although this is just a copy of the cvmfs files, so the changes should be done there (as already done for el9 actually). |
|
Well. Isn't this repo the authoritative source for the script on cvmfs? I thought we merely publish it there... directly from here. (Anything else appears be error-prone.) In any case, I don't know how to edit files on cvmfs. |
|
agreed. There are historical reasons for this and I guess it is time to fix them once I am back. |
| @@ -67,7 +67,7 @@ case $distro_name in | |||
| ;; | |||
| 8*) | |||
| distro_xrelease=8.x | |||
| platform=el7 | |||
| platform=el8 | |||
| # The above priority is a general search priority. However, given a platform, we should actually | ||
| # start searching for software matching this precise platform and only later fall back to other | ||
| # platforms. This prevents loading el9 or el7 software, when I am actually on el8 (and el8 software is available). | ||
| PLATFORM_PRIORITY="${platform}-$uname_m ${PLATFORM_PRIORITY//${platform}-$uname_m/}" |
There was a problem hiding this comment.
How can this happen? We should never have O2 / O2Physics tags for different architectures with the same name.
There was a problem hiding this comment.
I don't understand your question (but I suppose that we might in fact have the same name on different arches). This line fixes this problem mentioned above: "alienv executed inside el8 container loads el7 software, inconsistent with the choice of el8 container ... and despite the fact that el8 software A is actually available."
The fix is simply to look first of all if we have software for el8 ... instead of loading the el7 one simply because it is higher up the list. Refining the search list seems a reasonable thing to do and I don't see what might speak against this.
There was a problem hiding this comment.
This is a reproducer:
ssh lxplus8.cern.ch
/cvmfs/alice.cern.ch/bin/alienv enter O2sim::async-2023-pp-apass3-20240320.1-1
This fixes an inconsistency observed in GRID jobs when loading a software package "A".
The bug was:
Bug fixed by slightly adjusting the platform priority: We always search the current platform first of all before going elsewhere.