-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
If job requires rhel8 container, use slc7 python libraries #11077
Conversation
Testing it with vocms0192 and amaltaro_TC_EL8_Agent202_Val_220409_033647_4276. |
Jenkins results:
|
This doesn't work. Stage out fails with this error:
I guess we will have to do the same trick as we did for |
yes, we need COMP python for el8 cmssw release. I can create the symlinks, let me know what paths WMCore would be expacting under /cvmfs/cms.cern.ch/COMP? |
by the way, starting with Lines 141 to 149 in 844ccaf
and we create |
@smuzaffar your suggestion would be the ideal and most maintainable approach in my opinion. However, I don't feel comfortable with blindly using CMSSW-based builds to run the production job wrapper, reason is because there was no validation at all to running the WMCore runtime code with those libraries (python, future, and other packages that I see in cvmfs - gcc, zlib, bz2lib, etc) |
Shahzad, I guess we can start with a path like:
and maybe the same for the other 2 architectures (ppc64le and aarch64). We need only python3 and py3-future packages. |
I just wanted to have the code to support future archs. For example, for existing
and for new archs e.g.
Once these symlinks are available then all you need is to use
|
by the way, we are also in process of setting up jenkins jobs to test the system via crab jobs. This will allow us to automatically test new archs (e.g. |
@amaltaro , new archs are now available under
I also have created short symlink, so if you prefer please use these in submit script
|
@smuzaffar thank you very much, Shahzad!
I am giving this a try in my last commit that I just pushed in into this branch. Let's see how it goes with grid tests. |
etc/submit_py3.sh
Outdated
then | ||
WMA_SCRAM_ARCH=slc6_${THIS_ARCH}_gcc700 | ||
WMA_SCRAM_ARCH=slc7_${THIS_ARCH} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@amaltaro , may be rhel7
instead of slc7
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! Thanks!
Jenkins results:
|
689facc
to
bdea13d
Compare
Jenkins results:
|
Tests are still running, but I can already see a few 100s jobs all successfully completing. |
looks good to me. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made one comment how to improve the it is up to you to decide if you want to make it. From the point of view of required changes everything is fine and I'll approve it.
etc/submit_py3.sh
Outdated
then | ||
WMA_SCRAM_ARCH=slc6_${THIS_ARCH}_gcc700 | ||
WMA_SCRAM_ARCH=rhel7_${THIS_ARCH} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would rather define separate default flavor variable, e.g. DEFAULT_OS=rhl7
somewhere on the top of the script and then use it here. This makes it easy to maintain and avoid changing defaults somewhere down in a code. I usually prefer to have common definitions on top of the script and then have a line saying DO NOT EDIT below this line
to make clear separation between definitions and logic itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good suggestion, thanks Valentin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good to me
With these changes in, now the Cleanup jobs fail because I just noticed they do not define Thanks for the reviews everyone! |
Trying the new map of OS_ARCH replace slc7 by rhel7 apply Valentins suggestion
bdea13d
to
765a720
Compare
Jenkins results:
|
Having the agent patched with #11083 does the tricky and there are successful
Discussion is ongoing over the SI mattermost channel. |
other than the two transient issues mentioned above, this looks good to go and will be backported to the agent branch |
Fixes #11051
Complement to #11060 and #11062
Status
ready
Description
We do not have a build of COMP in EL8, so for jobs requesting
rhel8
, use our slc7_* python libraries.We might consider using python and future library from one of the EL8 CMSSW releases as well, still unsure whether that would work out of the box though.
UPDATE: these changes triggered a discussion with the SI team, and they actually updated the container to be used for
REQUIRED_OS=any
fromrhel6
torhel7
, on April 11, 2022. We need to check whether current production agents will behave properly.Is it backward compatible (if not, which system it affects?)
YES
Related PRs
Complement to #11060 and #11062
External dependencies / deployment changes
None