Skip to content
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

Closed
todor-ivanov opened this issue Apr 9, 2024 · 3 comments · Fixed by #11962
Closed

Allow Data Tier numbers in all fields at the lexicon #11961

todor-ivanov opened this issue Apr 9, 2024 · 3 comments · Fixed by #11962

Comments

@todor-ivanov
Copy link
Contributor

todor-ivanov commented Apr 9, 2024

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 DBS preprod + 12 service_config files for DBS prod

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

@todor-ivanov
Copy link
Contributor Author

@amaltaro @klannon, I have labeled the current issue as Operations and did not consider it as a new high priority development, but since it is a really high priority issue for T0 and the already started ata taking, I think we should pay extra attention to this. Please feel free to relabel it as you consider correct. In the meantime I'll create the PR for equalizing the DBS and WMCore sides. And this would allow me to at least reconfigure the DBS production server and let T0 start taking data with numbers in the Data Tier fields. Upon that I think we can relax the urgency of testing on the WMCore side.

@vkuznet
Copy link
Contributor

vkuznet commented Apr 9, 2024

@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.

@todor-ivanov
Copy link
Contributor Author

Thanks @vkuznet I completely agree...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants