Skip to content
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

Add edmDumpClassVersion and checkDictionaryUpdate.py scripts to check class version and checksum updates #45423

Merged
merged 10 commits into from
Jul 26, 2024

Conversation

makortel
Copy link
Contributor

@makortel makortel commented Jul 10, 2024

PR description:

This PR is a work-in-progress prototype of a edmDumpClassVersion script to print class versions and checksums of all (non-transient) classes defined in a classes_def.xml file. The script would be used in automated assignment of changes-dataformats label discussed in cms-sw/cms-bot#2245.

The command-line interface is similar to edmCheckClassVersion with the -x / --xml_file and -l / --lib parameters.

Resolves cms-sw/framework-team#947

PR validation:

Tested the output on DataFormats/Common/src/classes_def.xml.

If this PR is a backport please specify the original PR and why you need to backport that PR. If this PR will be backported please specify to which release cycle the backport is meant for:

Potentially to be backported to 14_0_X.

@cmsbuild
Copy link
Contributor

cmsbuild commented Jul 10, 2024

cms-bot internal usage

@cmsbuild
Copy link
Contributor

@cmsbuild
Copy link
Contributor

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

It involves the following packages:

  • FWCore/Utilities (core)

@Dr15Jones, @cmsbuild, @makortel, @smuzaffar can you please review it and eventually sign? Thanks.
@felicepantaleo, @missirol, @wddgit this is something you requested to watch as well.
@antoniovilela, @rappoccio, @sextonkennedy you are the release manager for this.

cms-bot commands are listed here

Copy link
Contributor Author

@makortel makortel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think FWCore/Utilities is not the best package for these utilities (mostly because of the dependence on ROOT).

Maybe FWCore/Reflection would be better? (although I feel it would not be a perfect match either)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved the code from edmCheckClassVersion that I wanted to re-use into this file (with a few changes that I'll note below).

There is enough of somewhat complicated code shared between edmCheckClassVersion and edmDumpClassVersion that I'd prefer to have the edmDumpClassVersion in CMSSW rather than in cms-bot (which then implies the need to backport to 14_0_X).

classVersionIndex=1
versionsToChecksumIndex = 2

def __init__(self, filename, includeNonVersionedClasses=False, normalizeClassNames=True):
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The includeNonVersionedClasses and normalizeClassNames are new options for this class. The default values are those used by edmCheckClassVersion (I could make that script to pass the values also explicitly). The edmDumpClassVersion uses opposite values.

Comment on lines -2 to -6
from sys import version_info
if version_info[0] > 2:
atol = int
else:
from string import atol
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just replaced all atol() calls with int().

@makortel
Copy link
Contributor Author

The present printout is along

edm::WrapperBase 4 3914746810
edm::EDProductGetter 11 2247759761
edm::RefCore 11 3425324092
edm::RefCoreWithIndex 11 2602044085
edm::ThinnedAssociation 10 1914950449
edm::Wrapper<edm::ThinnedAssociation> 4 2054679015

If we proceed by the bot prints the checksums of the baseline and of the baseline+PR for every PR test, this format might be sufficient (simple diff should be sufficient to tell if there are changes; in this case the output would probably be good to be sorted to avoid false positives from simple reordering of things in classes_def.xml).

If we proceed by having a storing the versions and checksums for all data format classes_def.xml files, the output would be better as something more machine-readable, e.g. JSON.

@makortel
Copy link
Contributor Author

@smuzaffar What way do you think would make most sense to use the version+checksum information in the PR tests?

@smuzaffar
Copy link
Contributor

@makortel , I am think something like the following

  • PR tests can generate and upload the version+checksum ref if not already available. Ref should be stored in one file per cmssw package
  • PR tests can generate a local version+checksum for the packages changed by PR . If a package is dropped/removed in PR then it should still generate an empty file.
  • Run a simple diff and report in PR summary that there are dataformat changes
  • Once PR tests are completed then bot can add the changes-dataformats label if needed. This label can be removed by L2 (using type -changes-dataformats comment) if it is false positive

Note that this will be done during PR tests and not during code-checks (we do not want to build/run anything during self started code-checks tests)

@makortel
Copy link
Contributor Author

@smuzaffar Ok, sounds good. Do I understand correctly that a simple text format (like presently in this PR) would be sufficient?

What about packages that have multiple classes_def.xml files? I'd (slightly) prefer this script to operate on one classes_def.xml file at a time, so would the bot then e.g. concatenate+sort the output of all classes_def.xml files into one file per package?

@smuzaffar
Copy link
Contributor

@makortel , for few classes_def.xml files edmDumpClassVersion failed with error like [a]. For packages which it failed are [b].

[a]

Traceback (most recent call last):
  File "/build/muz/cv/CMSSW_14_1_X_2024-07-11-2300/bin/el8_amd64_gcc12/edmDumpClassVersion", line 34, in <module>
    main(args)
  File "/build/muz/cv/CMSSW_14_1_X_2024-07-11-2300/bin/el8_amd64_gcc12/edmDumpClassVersion", line 22, in main
    (error, version, checksum) = ClassesDefUtils.checkClass(name, 0, {})
  File "/build/muz/cv/CMSSW_14_1_X_2024-07-11-2300/src/FWCore/Utilities/python/ClassesDefXmlUtils.py", line 95, in checkClass
    raise RuntimeError("failed to load dictionary for class '"+name+"'")
RuntimeError: failed to load dictionary for class 'std::pair<LocalVector,LocalVector>'

[b]

edmDumpClassVersion -l libAnalysisDataFormatsTrackInfo.so -x /cvmfs/cms-ib.cern.ch/sw/x86_64/week1/el8_amd64_gcc12/cms/cmssw-patch/CMSSW_14_1_X_2024-07-11-2300/src/AnalysisDataFormats/TrackInfo/src/classes_def.xml
edmDumpClassVersion -l libCondFormatsHcalObjects.so -x /cvmfs/cms-ib.cern.ch/sw/x86_64/week1/el8_amd64_gcc12/cms/cmssw-patch/CMSSW_14_1_X_2024-07-11-2300/src/CondFormats/HcalObjects/src/classes_def.xml
edmDumpClassVersion -l libDataFormatsEcalRecHitROCmAsync.so -x /cvmfs/cms-ib.cern.ch/sw/x86_64/week1/el8_amd64_gcc12/cms/cmssw-patch/CMSSW_14_1_X_2024-07-11-2300/src/DataFormats/EcalRecHit/src/alpaka/classes_rocm_def.xml
edmDumpClassVersion -l libDataFormatsHGCRecHit.so -x /cvmfs/cms-ib.cern.ch/sw/x86_64/week1/el8_amd64_gcc12/cms/cmssw-patch/CMSSW_14_1_X_2024-07-11-2300/src/DataFormats/HGCRecHit/src/classes_def.xml
edmDumpClassVersion -l libDataFormatsL1Trigger.so -x /cvmfs/cms-ib.cern.ch/sw/x86_64/week1/el8_amd64_gcc12/cms/cmssw-patch/CMSSW_14_1_X_2024-07-11-2300/src/DataFormats/L1Trigger/src/classes_def.xml
edmDumpClassVersion -l libDataFormatsTauReco.so -x /cvmfs/cms-ib.cern.ch/sw/x86_64/week1/el8_amd64_gcc12/cms/cmssw-patch/CMSSW_14_1_X_2024-07-11-2300/src/DataFormats/TauReco/src/classes_def_3.xml
edmDumpClassVersion -l libDataFormatsTrackSoAROCmAsync.so -x /cvmfs/cms-ib.cern.ch/sw/x86_64/week1/el8_amd64_gcc12/cms/cmssw-patch/CMSSW_14_1_X_2024-07-11-2300/src/DataFormats/TrackSoA/src/alpaka/classes_rocm_def.xml
edmDumpClassVersion -l libDataFormatsTrackingRecHitSoAROCmAsync.so -x /cvmfs/cms-ib.cern.ch/sw/x86_64/week1/el8_amd64_gcc12/cms/cmssw-patch/CMSSW_14_1_X_2024-07-11-2300/src/DataFormats/TrackingRecHitSoA/src/alpaka/classes_rocm_def.xml
edmDumpClassVersion -l libFireworksCore.so -x /cvmfs/cms-ib.cern.ch/sw/x86_64/week1/el8_amd64_gcc12/cms/cmssw-patch/CMSSW_14_1_X_2024-07-11-2300/src/Fireworks/Core/src/classes_def.xml
edmDumpClassVersion -l libOnlineDBEcalCondDB.so -x /cvmfs/cms-ib.cern.ch/sw/x86_64/week1/el8_amd64_gcc12/cms/cmssw-patch/CMSSW_14_1_X_2024-07-11-2300/src/OnlineDB/EcalCondDB/src/classes_def.xml
edmDumpClassVersion -l libSimGeneralTrackingAnalysis.so -x /cvmfs/cms-ib.cern.ch/sw/x86_64/week1/el8_amd64_gcc12/cms/cmssw-patch/CMSSW_14_1_X_2024-07-11-2300/src/SimGeneral/TrackingAnalysis/src/classes_def.xml
edmDumpClassVersion -l libSimTrackerTrackTriggerAssociation.so -x /cvmfs/cms-ib.cern.ch/sw/x86_64/week1/el8_amd64_gcc12/cms/cmssw-patch/CMSSW_14_1_X_2024-07-11-2300/src/SimTracker/TrackTriggerAssociation/src/classes_def.xml

@smuzaffar
Copy link
Contributor

smuzaffar commented Jul 12, 2024

@smuzaffar Ok, sounds good. Do I understand correctly that a simple text format (like presently in this PR) would be sufficient?

If I understand correctly, we do want to flag in case of any change in dataformat i.e. any new dict, removal of existing dict or change in checksum ... right? If yes then simple diff with this text format should be enough.

What about packages that have multiple classes_def.xml files? I'd (slightly) prefer this script to operate on one classes_def.xml file at a time, so would the bot then e.g. concatenate+sort the output of all classes_def.xml files into one file per package?

yes, bot will run single process per xml file but it will run nproc such process in parallel ( to speed up the processing). At the end it will concatenate+sort all the xmls for each package in its package file ( i.e. we will have one version-checksum file per package). Bot then can compare PR packages files with release packages file

@smuzaffar
Copy link
Contributor

smuzaffar commented Jul 12, 2024

@makortel , I also see some classes with -1 as version [a]. Is this expected ?

[a]

> edmDumpClassVersion -l libCondFormatsHcalObjects.so -x /cvmfs/cms-ib.cern.ch/sw/x86_64/week1/el8_amd64_gcc12/cms/cmssw-patch/CMSSW_14_1_X_2024-07-11-2300/src/CondFormats/HcalObjects/src/classes_def.xml
....
...
HcalCondObjectContainer<HcalLutMetadatum> -1 3488635253
HcalLutMetadata -1 1184932721
HcalLutMetadata::NonChannelData -1 1765044631
HcalDcsValue -1 3257269307

@makortel
Copy link
Contributor Author

@smuzaffar Ok, sounds good. Do I understand correctly that a simple text format (like presently in this PR) would be sufficient?

If I understand correctly, we do want to flag in case of any change in dataformat i.e. any new dict, removal of existing dict or change in checksum ... right?

Right, this is my understanding as well.

If yes then simple diff with this text format should be enough.

Ok, good. I'll then update the PR with the earlier review suggestions.

What about packages that have multiple classes_def.xml files? I'd (slightly) prefer this script to operate on one classes_def.xml file at a time, so would the bot then e.g. concatenate+sort the output of all classes_def.xml files into one file per package?

yes, bot will run single process per xml file but it will run nproc such process in parallel ( to speed up the processing). At the end it will concatenate+sort all the xmls for each package in its package file ( i.e. we will have one version-checksum file per package). Bot then can compare PR packages files with release packages file

Sounds good.

@makortel
Copy link
Contributor Author

I also see some classes with -1 as version [a]. Is this expected ?

I have no idea. I'll tag @pcanal in the hope we'd get an answer when he gets back.

@makortel
Copy link
Contributor Author

for few classes_def.xml files edmDumpClassVersion failed with error like [a]

Thanks, I'll take a look of these as well.

@smuzaffar
Copy link
Contributor

What about packages that have multiple classes_def.xml files?

yes bot will process all the xml files of the package. Also it will process any addition alpaka backend xml files

edmDumpClassVersion -l libDataFormatsStdDictionaries.so -x DataFormats/StdDictionaries/src/classes_def_vector.xml
edmDumpClassVersion -l libDataFormatsStdDictionaries.so -x DataFormats/StdDictionaries/src/classes_def_pair.xml
edmDumpClassVersion -l libDataFormatsStdDictionaries.so -x DataFormats/StdDictionaries/src/classes_def_others.xml
edmDumpClassVersion -l libDataFormatsStdDictionaries.so -x DataFormats/StdDictionaries/src/classes_def_map.xml
....
edmDumpClassVersion -l libDataFormatsBeamSpot.so -x DataFormats/BeamSpot/src/classes_def.xml
edmDumpClassVersion -l libDataFormatsBeamSpotCudaAsync.so -x DataFormats/BeamSpot/src/alpaka/classes_cuda_def.xml
edmDumpClassVersion -l libDataFormatsBeamSpotROCmAsync.so -x DataFormats/BeamSpot/src/alpaka/classes_rocm_def.xml

@davidlange6
Copy link
Contributor

why would you expect a class version != -1 for these?

<class name="HcalLutMetadatum"/>

@smuzaffar
Copy link
Contributor

@makortel , all look good

@makortel
Copy link
Contributor Author

+core

@cmsbuild
Copy link
Contributor

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. @sextonkennedy, @mandrenguyen, @rappoccio, @antoniovilela (and backports should be raised in the release meeting by the corresponding L2)

@mandrenguyen
Copy link
Contributor

@makortel
Would you please resolve the open discussion threads, just to confirm that this is ready to merged?

@makortel
Copy link
Contributor Author

Would you please resolve the open discussion threads, just to confirm that this is ready to merged?

I'd actually prefer to leave them open. 3 of them are my own comments about why some things were done (and there is nothing to react), and 1 is a question/suggestion for @smuzaffar (for which there is nothing to react in this PR). I feel all of them are more useful to be left open than closed for anyone looking at this PR in the future.

@mandrenguyen
Copy link
Contributor

mandrenguyen commented Jul 26, 2024

Would you please resolve the open discussion threads, just to confirm that this is ready to merged?

I'd actually prefer to leave them open. 3 of them are my own comments about why some things were done (and there is nothing to react), and 1 is a question/suggestion for @smuzaffar (for which there is nothing to react in this PR). I feel all of them are more useful to be left open than closed for anyone looking at this PR in the future.

Fair enough. But just to confirm, these are left open for the future, but the PR itself is ready to be merged (as the signatures already indicate)?

@makortel
Copy link
Contributor Author

But just to confirm, these are left open for the future, but the PR itself is ready to be merged (as the signatures already indicate)?

Correct.

@mandrenguyen
Copy link
Contributor

+1

@makortel
Copy link
Contributor Author

Coming back to the classes_def.xml files the script was unable to fully digest (i.e. continuation of #45423 (comment))

AnalysisDataFormats/TrackInfo/src/classes_def.xml

Fixed in #45564

DataFormats/TauReco/src/classes_def_3.xml

I need to talk to @pcanal to understand better best practices with type aliases in classes_def.xml files.

SimGeneral/TrackingAnalysis/src/classes_def.xml
SimTracker/TrackTriggerAssociation/src/classes_def.xml

Fixed in #45567

CondFormats/HcalObjects/src/classes_def.xml

Fixed in #45553

Fireworks/Core/src/classes_def.xml

Fixed in #45546

OnlineDB/EcalCondDB/src/classes_def.xml

Fixed in #45545

DataFormats/EcalRecHit/src/alpaka/classes_rocm_def.xml
DataFormats/TrackSoA/src/alpaka/classes_rocm_def.xml
DataFormats/TrackingRecHitSoA/src/alpaka/classes_rocm_def.xml

I'll look into next week

DataFormats/HGCRecHit/src/classes_def.xml

Fixed in #45551

DataFormats/L1Trigger/src/classes_def.xml

Fixed in #45554

@smuzaffar
Copy link
Contributor

yes, once this PR is merge then we can start running it for master IB production arch and report packages with policy checks failures

Ok. I'll add then a mode where the checkDictionaryUpdate.py can be run with --baseline only, and then I'd consider this PR complete (barring review feedback, of course).

@makortel , class versions results for IB/baseline are now available ( see the link on Ib page : https://cmssdt.cern.ch/SDT/jenkins-artifacts//class_versions/CMSSW_14_1_X_2024-07-28-2300/el8_amd64_gcc12/class_versions.html ). There are few errors e.g. there are errors like

Parsing [CondFormats/CastorObjects/src/classes_def.xml](https://github.com/cms-sw/cmssw/blob/CMSSW_14_1_X_2024-07-28-2300/CondFormats/CastorObjects/src/classes_def.xml) failed: There is an element 'class' without 'name' attribute.

@makortel
Copy link
Contributor Author

class versions results for IB/baseline are now available ( see the link on Ib page : https://cmssdt.cern.ch/SDT/jenkins-artifacts//class_versions/CMSSW_14_1_X_2024-07-28-2300/el8_amd64_gcc12/class_versions.html ). There are few errors e.g. there are errors like

Thanks! I'll start taking a look. I see they all are about the classes_def.xml having <class pattern="...">. I vaguely recall a campaign to remove those some (many?) years ago.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add utility to print class versions and checksums for automating setting changes-dataformats GitHub label
6 participants