-
Notifications
You must be signed in to change notification settings - Fork 108
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
Allow Data Tier numbers in all fields at the lexicon #11961
Comments
@amaltaro @klannon, I have labeled the current issue as |
@todor-ivanov , please note that I discussed Lexicon unification in (still open) WMCore issue #10614 where I suggested to move Lexicon to portable JSON format instead of Python based one used by WMCore. I think your concern is valid but it is related how we use Lexicon, and I still believe that using portable JSON format will be beneficial to manage lexicon. How and where these JSON files will be stored is a slightly different issue. |
Thanks @vkuznet I completely agree... |
Impact of the new feature
Everything
Is your feature request related to a problem? Please describe.
While allowing numbers in the DataTier field, we have not taken into account the fact we are not always building regular expressions from different fields and levels from the Namespace as they are defined here: https://twiki.cern.ch/twiki/bin/viewauth/CMS/DMWMPG_Namespace We are having multiple regular expressions defined in the Lexicon serving different purposes and if we want to make a change on a specific level at the namespace, we should find all relevant regula expression patterns in the lexicon and apply the change at the respective level.
We have realised this the hard way, by testing our changes for the DBS server in
preprod
here: [1]. Which led us to the quite unpleasant change at [2]. And to make things even funnier, since the leading source should always be the WMCore lexicon for all other services, this not that human readable change must be propagated to 25 files more or less - 1 file in the WMCore code (the lexicon itself) + 12 services_config files for DBSpreprod
+ 12 service_config files for DBSprod
This is a quite uncomfortable way for working, but it is as it is ... And the current issue is not to improve it, but rather to back propagate the change we have already proven is working for DBS, back to the lexicon at WMCore.
On the other this is a sign for the need of refactoring the Lexicon in general.
[1]
dmwm/dbs2go#108
https://gitlab.cern.ch/cmsweb-k8s/services_config/-/merge_requests/246
[2]
https://gitlab.cern.ch/cmsweb-k8s/services_config/-/merge_requests/248
Describe the solution you'd like
Back propagate the solution from https://gitlab.cern.ch/cmsweb-k8s/services_config/-/merge_requests/246 and https://gitlab.cern.ch/cmsweb-k8s/services_config/-/merge_requests/248 to the WMCore lexicon
Describe alternatives you've considered
None - it is a must do
Additional context
The text was updated successfully, but these errors were encountered: