-
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
Adopt CMS_PATH and SITECONFIG_PATH to locate the site catalog #11481
Conversation
Jenkins results:
|
@amaltaro I think WM should keep the propagation of |
Jenkins results:
|
Noted and code updated in the Scram module. Thanks Matti. |
Jenkins results:
|
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.
Thanks @amaltaro
I am only worried about backwards compatibility here. though, If we are sure the $SITECONFIG_PATH
is defined regardless of the CMSSW version, we seem to be safe.
@@ -39,11 +39,11 @@ def loadSiteLocalConfig(): | |||
msg = "%s env. var. provided but not pointing to an existing file, ignoring." % overVarName | |||
logging.log(logging.ERROR, msg) | |||
|
|||
defaultPath = "$CMS_PATH/SITECONF/local/JobConfig/site-local-config.xml" | |||
defaultPath = "$SITECONFIG_PATH/JobConfig/site-local-config.xml" |
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.
IIRC the ../local..
part from this path here is usually a sym. link related to the site name/setup. Are we sure it has been properly expanded in the $SITECONFIG_PATH
env. variable? Or should we even care to check, actually?... Maybe we just take it for granted and use what ever provided inside the environment? (just a thought here, no request for a change).
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.
@todor-ivanov we can take it from granted, it is handled in the cms-common script below:
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.
thanks @khurtado, indeed we can.
The way I understand it is that SITECONFIG_PATH is actually defined in the CMS pilot (the same as it is for CMS_PATH). So I'd simply take it for granted as we used to do for CMS_PATH. Regarding the |
This is correct. There is one detail in the conceptual difference between But I wonder if there is anything to be concerned about for CMSSW releases <= 12_6_0_pre1 that still use Maybe @stlammel would have a better view? |
Just some extra content here: From what I see, both variables get defined when sourcing
The environment variable An example for a file structure of a subsite would be Wisconsin and its CHTC resource (subsite resource of Wisconsin)
|
@khurtado Kenyi, but in this case wouldn't the worker node/pilot use a different In other words, it's up to the site admin to define the correct symlink that each site and subsite has to use. While our jobs simply set the environment and consume the actual catalog files provided by SITECONFIG_PATH (meant to have different different content between subsites, but still accessed through the same path). Or am I misunderstanding something in here? |
I believe the
where But yes, I was just putting some extra information there for the record, regarding what happens with this new variable. But for us, we ultimately don't care how this is set, we just take it for granted. The validation of these paths are done elsewhere (during the setup of a site or sub-site, during the pilot validation tests, etc). |
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 Changes to the actual python scripts look good to me, I only have some comments/changes requested to the unit tests.
@@ -155,7 +155,7 @@ def createTestWorkload(self, workloadName='Test', emulator=True): | |||
os.makedirs(siteConfigPath) | |||
shutil.copy('site-local-config.xml', siteConfigPath) | |||
environment = rereco.data.section_('environment') | |||
environment.CMS_PATH = workloadDir | |||
environment.SITECONFIG_PATH = workloadDir |
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.
Shouldn't SITECONFIG_PATH
be:
environment.SITECONFIG_PATH = "%s/SITECONF/local" % workloadDir
To make it consistent with the default definition here:
https://github.com/cms-sw/cms-common/blob/9c8203bf637b153697b855dfa522d6741379bcc9/cmsset_default.sh#L40-L44
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 am not sure from the L153 above. Maybe it even does not really matter, but let me make this change.
@@ -155,7 +155,7 @@ def testSlcPhedexNodesEqualPhedexApiNodes(self): | |||
For each site, verify that the stageout node specified in | |||
site-local-config.xml is the same as the one returned by the PhEDEx api. | |||
""" | |||
os.environ["CMS_PATH"] = "/cvmfs/cms.cern.ch" | |||
os.environ["SITECONFIG_PATH"] = "/cvmfs/cms.cern.ch/SITECONFIG/local" |
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.
Replace SITECONFIG
with SITECONF
in the cvmfs path
So sites are keeping access via both CMS_PATH (for older CMSSW versions) and SITECONFIG_PATH (for newer CMSSW versions) working right now. How the local link in CVMFS is set is up to each site. Most sites set it to the sitename and site/subsite for subsites but in case of a local SITECONF copy this doesn't need to be the case. ${CMS_PATH}/SITECONF/local is guaranteed to point to a good SITECONF area and ${SITECONF_PATH}.
|
Jenkins results:
|
Jenkins results:
|
Thanks for the review, @khurtado. Some unit tests were actually broken and I managed to get them fixed with this PR. For now, I kept unit tests defining both environment variables, as you suggested. Please have another look |
@amaltaro Looking good! There is just one unit test that I think is still missing the |
Keep CMS_PATH around in the Scram module
more fixes to unit tests trying to run integration unit test fix stageout unit test
Jenkins results:
|
Thank you for the review and further tests! |
Thanks everybody for discovering and handling the dependency! - Stephan |
Thanks @germanfgv! Does this mean we could safely switch 12_6_X back to RucioCatalog? |
@makortel I still would like to test how it will work with T2_CH_CERN_P5 worker nodes. I'll launch test this tonight with a replay. |
Thanks @germanfgv! |
@germanfgv In the mean time I took the liberty of opening a PR to change the file catalog to Rucio catalog in 12_6_X in cms-sw/cmssw#40755 . If your tests succeed and the PR could proceed, could mention it in that PR as well? |
Fixes #11449
Status
not-tested
Description
In light of the migration from storage.xml to storage.json, CMSSW went through some modifications to support those catalogs, in short:
That means, our Scram module needs to keep explicitly defining those variables in the CMSSW environment. As confirmed by Matti below, it should not be a problem to have both variables defined.
Is it backward compatible (if not, which system it affects?)
YES (to the best of my knowledge)
Related PRs
Somehow related to #11472
External dependencies / deployment changes
None