You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
@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.
@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.
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: