GT Initialization: ignoring non-existing record in the plugins pre-load

[ggovi]

PR description:

CMSSW Workflows requiring the consumption of conditions can be successfully executed when all the records involved in the code are represented by their corresponding entries in the Global Tag loaded from the Condition Database.

Conversely, additional Records included in the GT Record-Tag map could be ignored when they are not involved in the Workflow code. This is the case, for instance, of Records that have been completely removed from the CMSSW Code.

This PR is addressing this last particular circumstance. The GT initialisation has been modify to ignore the Records for which the corresponding plugin can't be found in CMSSW.

The new behaviour is obviously applied to Records added manually with toGet statements, when not present in the release.

Note that these changes are not altering the current behaviour for other possible mis-matches between release and database, that could happen at later stage in the processing:

• Failures produced when no suitable IOV is found for a record invoked in the Workflow
• Failures produced when the payload to be used for a given record cannot be read in the release, because written with a higher boost version
• Failures produced when the Record, associated to given CondFormat in the release, is mapped in the GT, to a Tag populated with payloads from a different class ( this is normally forbidden by policy )

PR validation:

Integration test, executed with a specific GT (106X_mcRun2_asymptotic_v15) triggering in 12X the condition of 'missing record plugin'

[cmsbuild]

-code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-33798/22771

• This PR adds an extra 20KB to repository

Code check has found code style and quality issues which could be resolved by applying following patch(s)

• code-format:
  https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-33798/22771/code-format.patch
  e.g. curl https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-33798/22771/code-format.patch | patch -p1
  You can also run scram build code-format to apply code format directly

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-33798/22773

• This PR adds an extra 20KB to repository

[cmsbuild]

A new Pull Request was created by @ggovi for master.

It involves the following packages:

CondCore/ESSources

@malbouis, @yuanchao, @cmsbuild, @tlampen, @ggovi, @pohsun, @francescobrivio can you please review it and eventually sign? Thanks.
@mmusich, @tocheng this is something you requested to watch as well.
@silviodonato, @dpiparo, @qliphy you are the release manager for this.

cms-bot commands are listed here

[ggovi]

please test

[cmsbuild]

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-dd3d9b/15211/summary.html
COMMIT: b204123
CMSSW: CMSSW_12_0_X_2021-05-20-1100/slc7_amd64_gcc900
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week1/cms-sw/cmssw/33798/15211/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

Summary:

• No significant changes to the logs found
• Reco comparison results: 7 differences found in the comparisons
• DQMHistoTests: Total files compared: 37
• DQMHistoTests: Total histograms compared: 2650486
• DQMHistoTests: Total failures: 12
• DQMHistoTests: Total nulls: 1
• DQMHistoTests: Total successes: 2650451
• DQMHistoTests: Total skipped: 22
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.004 KiB( 36 files compared)
• DQMHistoSizes: changed ( 312.0 ): 0.004 KiB MessageLogger/Warnings
• Checked 155 log files, 37 edm output root files, 37 DQM output files
• TriggerResults: no differences found

[ggovi]

+1

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-33798/22864

• This PR adds an extra 20KB to repository

[cmsbuild]

Pull request #33798 was updated. @malbouis, @yuanchao, @cmsbuild, @tlampen, @ggovi, @pohsun, @francescobrivio can you please check and sign again.

[ggovi]

please test

[cmsbuild]

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-dd3d9b/15310/summary.html
COMMIT: 73a4013
CMSSW: CMSSW_12_0_X_2021-05-25-2300/slc7_amd64_gcc900
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/33798/15310/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

Summary:

• No significant changes to the logs found
• Reco comparison results: 0 differences found in the comparisons
• DQMHistoTests: Total files compared: 37
• DQMHistoTests: Total histograms compared: 2650486
• DQMHistoTests: Total failures: 1
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 2650463
• DQMHistoTests: Total skipped: 22
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 36 files compared)
• Checked 155 log files, 37 edm output root files, 37 DQM output files
• TriggerResults: no differences found

[ggovi]

+1

[francescobrivio]

+alca

[cmsbuild]

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. @silviodonato, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2)

[silviodonato]

@fwyzard asked by e-mail what happens if a record class is changed (from v1 to v2).
If I've understood correctly, CMSSW will check if a payload of the required record (v2) is contained in the global tag and it will give error if the record is missing, even if a payload of the old record (v1) is contained.
Same thing happens if the differences between the two classes two incompatible versions of boost.
https://groups.cern.ch/group/cms-release-dataops/Lists/Archive/Flat.aspx?RootFolder=%2Fgroup%2Fcms%2Drelease%2Ddataops%2FLists%2FArchive%2FPolicy%20for%20Removal%20of%20Condition%2Drelated%20record%20from%20CMSSW&FolderCTID=0x01200200730B983A7D7A6A42AC4F2B748B8D1551

Shortly, in both cases, there is no risk to read a payload in a wrong way.

@ggovi have I understood it correctly?

[ggovi]

The record class in itself cannot change, as its scope is essentially labelling a data consumption context. In theory, what can be changed is the CondFormat class associated via the macro 'REGISTER_PLUGIN'. This change is already forbidden by policy. Anyhow, non-spotted changes of this type cannot cause mis-interpreted reading of stored payload, as the de-serialization is attempted only when the payload class matches the record class. In case of mis-match, an exception is thown at the payload consuming time. This behavior is not altered by the present PR.

[silviodonato]

+1