-
Notifications
You must be signed in to change notification settings - Fork 36
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
Potential problems getting country groups in ProxyInteractions.py #5351
Comments
In case of
In addition, |
Hi @ArturAkh The original documentation says that FQAN format is Which exact problem do you have because of this ? I have similar attributes in my proxy and everything worls. Is there any hope that we can instead stop worrying about VOMS groups and roles in CRAB submission ? All groups are listed in the user proxy anyhow. And I'd be very happy to simplify the code. Should we involve "those who introduced those /../../.. attributes" ? |
Hi Stefano, We have a use-case where regional groups like At KIT - and I'd assume also at other German CMS institutions - we have used that for the access to storage. A way out of that would be for us the automatic assignment of the country group This assignment is e.g. visible in the new IAM CMS service: https://cms-auth.web.cern.ch/dashboard#!/home This use-case is not covered currently by group & role checks in crab, such that e.g. submission fails - at least when I have tested that last time with an attempt of having |
but the proxy which is presented to your servers should still list all those VOMS attributes. Simply CRAB will not be able to force one of them to be first of the list.
but
|
my bad, wrong syntax, this works
|
can your storage look at the list of attributes and check if country/de is there ? |
Hi Stefano, Our storage takes /cms/country/de for writing into account, in the same way as /cms/dcms I'll have a look at the exact error I've encountered and come back to you on Monday. As far as I remember it was during submission of a crab task. |
Here is what I see when trying to submit a task with Crab configuration setup within CMSSW_13_0_21: from WMCore.Configuration import Configuration
config = Configuration()
config.section_('General')
config.General.instance = 'prod'
config.General.requestName = 'data_2018UL_tau_Tau_Run2018A'
config.General.workArea = '/afs/cern.ch/work/a/aakhmets/private/htt_data_crab_nanoaod_submission_25-11-2024_prodreleasev12/crab'
config.section_('JobType')
config.JobType.maxMemoryMB = 4000
config.JobType.pluginName = 'Analysis'
config.JobType.psetName = '/afs/cern.ch/work/a/aakhmets/private/htt_data_crab_nanoaod_submission_25-11-2024_prodreleasev12/cmsdriver/2018UL/nano_config.py'
config.JobType.numCores = 8
config.JobType.maxJobRuntimeMin = 900
config.section_('Data')
config.Data.unitsPerJob = 1000000
config.Data.splitting = 'EventAwareLumiBased'
config.Data.outputDatasetTag = 'data_2018UL_tau_Tau_Run2018A_1732527119'
config.Data.publication = True
config.Data.inputDataset = '/Tau/Run2018A-UL2018_MiniAODv2_GT36-v1/MINIAOD'
config.section_('Site')
config.Site.storageSite = 'T1_DE_KIT_Disk'
config.Site.whitelist = None
config.Site.blacklist = None
config.section_('User')
config.User.voGroup = 'country/de'
config.section_('Debug') PSet configuration was created via: cmsDriver.py nano --data --filein file:inputfile.root --fileout nano.root --step NANO --eventcontent NANOAOD --datatier NANOAOD --python_filename /afs/cern.ch/work/a/aakhmets/private/htt_data_crab_nanoaod_submission_25-11-2024_prodreleasev12/cmsdriver/2018UL/nano_config.py --conditions auto:run2_data --era Run2_2018,run2_nanoAOD_106Xv2 --no_exec --nThreads 8 --nStreams 0 Result when running [aakhmets@lxplus9119 CMSSWWithCrab]$ crab submit /afs/cern.ch/work/a/aakhmets/private/htt_data_crab_nanoaod_submission_25-11-2024_prodreleasev12/crabconfigs/data_2018UL_tau_Tau_Run2018A.py
Will use CRAB configuration file /afs/cern.ch/work/a/aakhmets/private/htt_data_crab_nanoaod_submission_25-11-2024_prodreleasev12/crabconfigs/data_2018UL_tau_Tau_Run2018A.py
Importing CMSSW configuration /afs/cern.ch/work/a/aakhmets/private/htt_data_crab_nanoaod_submission_25-11-2024_prodreleasev12/cmsdriver/2018UL/nano_config.py
**************************************************************
b tagging needs to be run on uncorrected jets. Hence, the JECs
will first be undone for 'updatedPatJetsWithDeepInfo' and then applied to
'updatedPatJetsTransientCorrectedWithDeepInfo'.
**************************************************************
Finished importing CMSSW configuration /afs/cern.ch/work/a/aakhmets/private/htt_data_crab_nanoaod_submission_25-11-2024_prodreleasev12/cmsdriver/2018UL/nano_config.py
You are requesting more than 1 core per job. Please make sure that your multi-threaded code is thread-safe and CPU-efficient, and request the correct amount of memory since the default 'maxMemoryMB' value is meant for single core jobs.
Sending the request to the server at cmsweb.cern.ch
Fatal error trying to connect to https://cmsweb.cern.ch:8443/crabserver/prod/workflow using dryrun=0&workflow=crab_data_2018UL_tau_Tau_Run2018A&saveoutput=1&savelogsflag=0&inputdata=%2FTau%2FRun2018A-UL2018_MiniAODv2_GT36-v1%2FMINIAOD&nonvaliddata=0&dbsurl=https%3A%2F%2Fcmsweb.cern.ch%2Fdbs%2Fprod%2Fglobal%2FDBSReader&useparent=0&ignorelocality=0&splitalgo=EventAwareLumiBased&algoargs=1000000&totalunits=0&publication=1&publishdbsurl=https%3A%2F%2Fcmsweb.cern.ch%2Fdbs%2Fprod%2Fphys03%2FDBSWriter&publishname2=data_2018UL_tau_Tau_Run2018A_1732527119&jobtype=Analysis&generator=pythia&maxjobruntime=900&numcores=8&maxmemory=4000&priority=10&nonprodsw=0&asyncdest=T1_DE_KIT_Disk&requireaccelerator=0&vogroup=country%2Fde&oneEventMode=0&ignoreglobalblacklist=0&partialdataset=0&jobarch=el9_amd64_gcc11&jobsw=CMSSW_13_0_21&cacheurl=https%3A%2F%2Fcmsweb.cern.ch%2FS3%2Fcrabcache_prod&cachefilename=e698dbf940fa49516dde6b62f8780ee6acddcffec0027be3dfd526c59c071433.tar.gz&debugfilename=37294ab56cc27ea9357f202ddcafa1bb0702106fe54441db010418b91fe7b495.tar.gz&edmoutfiles=nano.root.
exit code from curl = 0
HTTP code/reason = 400/Bad Request . stdout:
<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></meta>
<title>400 Bad Request</title>
<style type="text/css">
#powered_by {
margin-top: 20px;
border-top: 2px solid black;
font-style: italic;
}
#traceback {
color: red;
}
</style>
</head>
<body>
<h2>400 Bad Request</h2>
<p>Invalid input parameter</p>
<pre id="traceback"></pre>
<div id="powered_by">
<span>
Powered by <a href="http://www.cherrypy.dev">CherryPy 18.8.0</a>
</span>
</div>
</body>
</html>
The server answered with an error.
Server answered with: Invalid input parameter
Reason is: Incorrect 'User.voGroup' parameter <class 'str'> country/de
Error Id: d682464c910061d84731ee25b2ec8f9b So it might well be, that this is rather related to a server-side error |
I am have no problem in believing that |
I'm afraid this is not covered in the dCache implementation currently. Only akhmet@bms1:/work/akhmet $ voms-proxy-info -fqan
/cms/Role=NULL/Capability=NULL
/cms/compute/Role=NULL/Capability=NULL
/cms/compute/scope/Role=NULL/Capability=NULL
/cms/country/Role=NULL/Capability=NULL
/cms/country/de/Role=NULL/Capability=NULL
/cms/dcms/Role=NULL/Capability=NULL
akhmet@bms1:/work/akhmet $ gfal-copy 475B44E0-2258-764C-B825-DB88FF682ACC.root davs://cmsdcache-kit-disk.gridka.de:2880/pnfs/gridka.de/cms/disk-only/store/user/aakhmets/test.root
Copying file:///work/akhmet/475B44E0-2258-764C-B825-DB88FF682ACC.root [FAILED] after 0s
gfal-copy error: 17 (File exists) - TRANSFER ERROR: Copy failed (streamed). Last attempt: HTTP 403 : Permission refused (destination)
akhmet@bms1:/work/akhmet $ voms-proxy-info -fqan
/cms/country/de/Role=NULL/Capability=NULL
/cms/Role=NULL/Capability=NULL
/cms/compute/Role=NULL/Capability=NULL
/cms/compute/scope/Role=NULL/Capability=NULL
/cms/country/Role=NULL/Capability=NULL
/cms/dcms/Role=NULL/Capability=NULL
akhmet@bms1:/work/akhmet $ gfal-copy 475B44E0-2258-764C-B825-DB88FF682ACC.root davs://cmsdcache-kit-disk.gridka.de:2880/pnfs/gridka.de/cms/disk-only/store/user/aakhmets/test.root
Copying file:///work/akhmet/475B44E0-2258-764C-B825-DB88FF682ACC.root [DONE] after 0s And arguing with dCache developers may not lead to solutions on a short time-scale... |
I see. I can look into expanding the VOMS group handling to support this, it will likely require changes both in client and server. It is not a very short time scale either. Artur, can you please clarify where exactly this "writing to your dCache" happens ? Is this during final output file storage via ASO ? We do not execute |
One possible solution to avoid changes in crab/dCache/FTS would be that new users with I hope something like that can be deployed on that level, maybe @stlammel could comment |
I think this is an artifact on how IAM maps groups to VOMS-groups. Panos and i will take a look. Give us a few days.
|
OK, sounds good, thanks a lot, Stephan! |
There might be an issue in ProxyInteractions.py
when trying to get the group in cases like:
The handling of groups and roles would need a more general treatment (e.g. considering everything between
/cms
and the first/Role=
as a group)The text was updated successfully, but these errors were encountered: