-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Fixes to allow the parallel use of ORA db and new CondDB #1831
Conversation
A new Pull Request was created by @ggovi for CMSSW_7_0_X. Fixes to allow the parallel use of ORA db and new CondDB It involves the following packages: CondCore/CSCPlugins @apfeiffer1, @nclopezo, @demattia, @danduggan, @rovere, @cmsbuild, @rcastello, @deguio, @ggovi, @eliasron, @mulhearn can you please review it and eventually sign? Thanks. |
+1 On Mon, Dec 16, 2013 at 4:28 PM, cmsbuild notifications@github.com wrote:
Thanks, |
-1 ---> test runtestTqafTopJetCombination had ERRORS you can see the results of the tests here: |
Pull request #1831 was updated. @apfeiffer1, @nclopezo, @demattia, @danduggan, @rovere, @cmsbuild, @rcastello, @deguio, @ggovi, @eliasron, @mulhearn can you please check and sign again. |
+1 |
Ok, I have produced a fix to support the old convention in GT naming (postfix "::All" ). With this fix, the two tests are reading correctly the GT, but failing with the following error: ----- Begin Fatal Exception 17-Dec-2013 17:33:51 CET----------------------- The target IOV starts effectively from 1/1:
The code previous to my changes was somewhat 'tolerating' this invalid requests. This brings us to a question for Framework people: is the request for run 1, lumi 0 expected/correct? Giacomo |
It is both expected and correct. Basically it is the begin run. |
+1 On Di., Dez. 17, 2013 at 5:54 nachm., Chris Jones <notifications@github.com="mailto:notifications@github.com">> wrote: This brings us to a question for Framework people: is the request for run 1, lumi 0 expected/correct? It is both expected and correct. Basically it is the begin run. Hmmm ... while I would expect this to be only correct for run- and time- based conditions, for lumi-based ones this implies that any IOV has to start at lumi=0 instead of lumi=1 as it is so far (at least in the ones used in these tests, potentially for many more). If this is the case, we will need to check and update all lumi-based conditions to make sure they contain lumi=0. Thanks, Cheers, andreas |
Andreas, I'm not sure I understand your last comment, but to clarify, 0 is not a valid luminosity section number. |
Two possible fixes for the tests then:
On Dec 17, 2013, at 5:54 PM, Chris Jones wrote:
|
The target 'time' which is being looked up in the iov is 4294967296 . Not 1. This should mean run 1, lumi 0. |
Pull request #1831 was updated. @apfeiffer1, @nclopezo, @demattia, @danduggan, @rovere, @cmsbuild, @rcastello, @deguio, @ggovi, @eliasron, @mulhearn can you please check and sign again. |
Bill, thanks for the clarification - this is what I thought it should be. :) In this case, as there is no valid lumi number for beginRun, I think the Thanks, |
+1 |
Andreas,
In either case, if a user attempts to read the data at a Run boundary they will get an exception. |
Hi Chris, Based on your clarification - and given the current Framework behavior at begin run - the IOV lookup should never fail. It is the actual payload access that might eventually fail with an exeception. So, I will go for 1) in PoolDBESSource and 2a) Thanks, Giacomo On Dec 17, 2013, at 10:28 PM, Chris Jones wrote:
|
Hi Chris, all,
We were planning to provide an optimisation to be able to read a whole GT Thanks, |
-1 ---> test runtestTqafTopEventSelection had ERRORS you can see the results of the tests here: |
+1 Well, that is now due to the fact that we do a more strict checking of [or, asked differently: how many +1's do I have to send to make the -1 from Thanks, |
The rationale has always been: "if you break something, you fix it (or you follow up to have it fixed)". In this particular case you have changed the behaviour so either you resume the old behaviour and call for its deprecation or you adapt everyone else to follow it. |
@demattia, @rcastello, @eliasron, @mulhearn we'd need to get this in pre11 (and 700) so could you please sign again ? The last commits were only in CondCore packages - though you may want to double check again :) Thanks - and seasonal greetings ! :)
|
for DQM and Validation I have signed it already. seasonal greetings to all! |
+1 |
@nclopezo can you please restart the tests? |
@apfeiffer1 I guess I'm still not being successful in my communication. I'll take a different tack: I'll describe what I think you mean by First, as I said before, the framework has always had So I assume that when you say ``requesting conditions for illegal lumi (0)` you mean there is a (possibly small) subset of conditions which are only defined within a lumi and do not have a legitimate value at begin run. An example would be the integrated luminosity for a given lumi block. The framework gives two ways to accommodate that behavior. However, first I need to review how the framework deals with new transitions. On each new Run or LuminosityBlock (and formerly Event) transition the framework needs to know if data in the EventSetup needs to be updated. It does that by seeing if the IOVSyncValue of the new transition lies within the IOV of each EventSetup Record being used. If the IOVSyncValue lies outside of a particular Record's last IOV, then the framework will call the ESSource's So in the case where a source knows it has no valid data for a particular Record for a given IOVSyncValue, the source can either
I personally prefer 1) in this case since it is likely you know exactly when the next good IOV is (presumable As an aside, a quick cursory look at your code change sees to show that you threw an exception during the |
@nclopezo any idea what happened of the tests? |
Mmm… a bunch of workflows failed. any idea? |
Testing again to see if there was some infrastructural problem. |
still fails a bunch of workflows (e.g. 100X). Moving this to pre12 / 71X. |
@nclopezo can you restart these tests? Thanks. |
ok, I restarted them with CMSSW_7_0_X_2014-01-09-0200 |
-1 you can see the results of the tests here: |
Hi, I have successfully tested the failing workflows. Can you please re-start the merging procedures? Otherwise, let me know if you prefer a new pull request. |
Pull request #1831 was updated. @apfeiffer1, @ojeda, @danduggan, @rovere, @cmsbuild, @diguida, @rcastello, @deguio, @ggovi, @Degano, @mulhearn, @nclopezo can you please check and sign again. |
Va ancora bene 70X... On 10 Jan 2014, at 22:04, Giacomo Govi wrote:
On 13 Jan 2014, at 12:03, cmsbuild wrote:
|
+1 |
+1 |
+1 |
1 similar comment
+1 |
This pull request is fully signed and it will be integrated in one of the next IBs unless changes (tests are also fine). @ktf can you please take care of it? |
DB improvements -- Fixes to allow the parallel use of ORA db and new CondDB
Hi, I believe it it this pull request which lets the HLT crash in all AddOn tests such as these: Please have a look and fix for pre12. |
Some more info: The crash occurs in: void IOVProxy::load( const std::string& tag, bool full )
Note it is NOT the exception thrown in the body of the if statement, rather, the evaluation of the The values of the parameters are: tag=DTVdrift_V02_mc timetype=0 seems fine as it is used w/o problems in other calls. |
Yes I'm already producing the fix. Thanks Giacomo
|
This pull request removed what introduced by 1665. I am not sure how this happen. |
Ok, i'll create a pull request with the removed changes. On Jan 24, 2014, at 12:04 PM, Vincenzo Innocente wrote:
|
On 24 Jan, 2014, at 12:44 PM, ggovi notifications@github.com wrote:
|
The Condition Database implementation (write/read) has been modified to allow the access to both the old format (ORA/Pool) and the new schema (CondDB).