[ehellbar]

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.

[github-actions]

REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0
async-2024-PbPb-apass1
async-2024-ppRef-apass1
async-2024-PbPb-apass2
async-2023-PbPb-apass5