Repository navigation
Commit 5c2b525
committed
[WIP] Get CCDB time machine timestamp from CCDB by default in anchorMC.sh
Related JIRA ticket: https://its.cern.ch/jira/browse/O2-6543
This will use the script GRID/utils/getCCDBTimeMachineTimestamp.py in anchorMC.sh to obtain the CCDB time machine timestamp from the CCDB (or estimate it from the given anchored apass output files). This is now the default behavior. If the timestamp cannot be obtained, anchorMC.sh exits with an error. If set, the JDL vairable `ALIEN_JDL_CCDB_CONDITION_NOT_AFTER` can still be used to set the `--condition-not-after` timestamp by hand instead of obtaining it from CCDB.
The default object path for the time machine timestamp is `Users/a/aliprod/CCDBTimeMachineTS`. All objects are uploaded with validity `1:2`, and the metadata contains the pass, period, NotAfter and LPMProductionTag (to track the productions which uploaded the object). So there should be one object per reconstruction pass per period, valid for all runs of the given pass and period. Some test examples are already uploaded in http://ccdb-test.cern.ch:8080/browse/Users/e/ehellbar/CCDBTimeMachineTS.
This PR contains two commits:
1) in getCCDBTimeMachineTimestamp.py
- add a second CCDB query to check for existing objects right before the upload of a new object, to check if between the last empty query and now (after the estimation of the not-after timestamp from the reco output) another job was faster and already uploaded the object. This is an attempt to avoid duplicate objects for the same period/pass uploaded by a single LPMProductionTag. NB: a more elegent way to create these CCDBTimeMachineTS objects by default could be at the beginning or the end of the actual data reconstruction pass.
2) use getCCDBTimeMachineTimestamp.py in anchorMC.sh to obtain the CCDB time machine timestamp by default, keeping the current `ALIEN_JDL_CCDB_CONDITION_NOT_AFTER` option to enforce it by hand
I mark this as WIP since the following is still missing:
- treatment of MC specific CCDB objects: There is a handful of MC CCDB paths (TPC corrections, GLO/Param/MatLUT) for which the objects are uploaded independently of the data calibration objects, so the NotAfter as it is obtained here might invalidate the correct object to use. With Giulio, Ruben and Costin, we are working on an elegant way to handle this.
- I still need to run a small test on the grid to finally validate the implementation.1 parent 3ba2a77 commit 5c2b525
1 file changed
Lines changed: 23 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
354 | 354 | | |
355 | 355 | | |
356 | 356 | | |
357 | | - | |
| 357 | + | |
| 358 | + | |
| 359 | + | |
| 360 | + | |
| 361 | + | |
| 362 | + | |
| 363 | + | |
| 364 | + | |
| 365 | + | |
| 366 | + | |
| 367 | + | |
| 368 | + | |
| 369 | + | |
| 370 | + | |
| 371 | + | |
| 372 | + | |
| 373 | + | |
| 374 | + | |
| 375 | + | |
| 376 | + | |
| 377 | + | |
| 378 | + | |
| 379 | + | |
358 | 380 | | |
359 | 381 | | |
360 | 382 | | |
| |||
0 commit comments