-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
MEtoEDMConverter does not need synchronizing on Run and Lumi boundaries #25105
Conversation
Using a RunCache and LuminosityBlockCache signals to the framework the module will not require synchronization on those boundaries.
The code-checks are being triggered in jenkins. |
please test |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-25105/7099 |
The tests are being triggered in jenkins. |
A new Pull Request was created by @Dr15Jones (Chris Jones) for master. It involves the following packages: DQMServices/Components @kmaeshima, @cmsbuild, @andrius-k, @jfernan2, @schneiml can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
+1 The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
@Dr15Jones while I believe your reasoning is right, we should check that the output produced is still correct. I remember this is a fairly fragile mechanism and it might rely on undefined behavior in the framework. I'll try to find the wf that tests this module (IIRC there is one) and check. |
@schneiml I completely agree that this needs proper testing before being used for production work. Again, I encourage the DQM L2s to work with @fabiocos @smuzaffar and myself to create automated testing systems for the DQM modules. This is particular important as changes to the DQM modules will be needed to accomodate the greater concurrency needed during Run 3 and Run 4. |
@Dr15Jones I agree on better testing, but in this case the situation is a bit different: the code actually runs, but currently we don't really look at the infrastructure that compares DQM output (esp. not for these "non-standard" configurations). And yes, I have some plans for the long shutdown, and better testing infrastructure is a big precondition for that. Actually, some test coverage tool would be cool... |
This change does not change the timing of when the framework calls the member functions of this module, i.e. it is still called on globalEndLuminosityBlock. Therefore it should be no better or worse if the code is relying on undefiled behavior. |
@Dr15Jones good to hear. I wanted to repeat the test from back in #22281 (basically run 1001/1004 and check if all the root files have properly filled histograms), but didn't get to it yet. |
@schneiml there is no rush from my side. Please run the test when it is convenient. |
Hi Chris, seems I forgot to report here that I did this test and nothing interesting happened (which is good). So no concerns from my side. |
@schneiml Is there anything you need done before you sign this pull request? |
+1 |
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @davidlange6, @slava77, @smuzaffar, @fabiocos (and backports should be raised in the release meeting by the corresponding L2) |
@fabiocos what is your plan for integrating this? |
1 similar comment
@fabiocos what is your plan for integrating this? |
+1 @Dr15Jones sorry, this was left behind in the flood of recent updates, as @schneiml tests do not show any issue, let's see in the IB |
@fabiocos The tests run in the |
Using a RunCache and LuminosityBlockCache signals to the framework
the module will not require synchronization on those boundaries.