CMSSW 15 won't support microarch-v2

[mmascher]

Impact of the new feature It was decided at the O&C week that starting from CMSSW 15 we won't build CMSSW for microarch v2. v1 has already been excluded and is not supported anymore. We need to make sure that jobs that will have a requirement for microarch x86_64-v[34] when they need to run on CMSSW15.

Additional context Microarch can be found on the slots as:

[mmascher@vocms4100 ~]$ condor_status -af Microarch | sort | uniq -c
     15 x86_64-v1
  12810 x86_64-v2
 113836 x86_64-v3
  38921 x86_64-v4

[mmascher]

Adding an email from antonio about this:

Hi Phat,

Thanks, we discussed this in the SI meeting today. Marco will open an issue, where we have to discuss basically 2 items:

• how (and who) should be doing the mapping between CMSSW versions and desired micro arch? In my opinion, this should happen in WM, which translates the request constraints into actual resource requirements.

• where should we implement the matchmaking constraint for the micro arch, as general condition on the pilots, or rather as additional requirements for the jobs? We discussed it could be done in WM, if this is exclusive to production jobs, or rather insert it as a general condition in the slot matching requirements, if we expect this to somehow also affect analysis jobs in the future.

Cheers, Antonio

[srimanob]

Thanks @mmascher

More discussion is ongoing as sites show concern if their people can't analyze Run 3 data with newer CMSSW. The current proposal is at the end of the comment. (2) is on WM+SI part

==========

(1) Building CMSW with Dual Version Compatibility (v2 + v3):

• We continue to build CMSW with both v2 and v3, allowing cmssw/scram to select the version that best matches the available CPU architecture.
• This approach enables analyzers using resources that only support v2 to still access and analyze data with the latest CMSSW versions.
• All external dependencies are built with v2, maintaining compatibility for systems limited to this architecture. The situation will be the same as HLT at this moment.

(2) Central production:

• By implementing a matching condition, jobs submitted with CMSSW_15_0_0 (and later) are directed to sites that support v3-only CPUs.
• Sites restricted to v2 CPUs will continue to receive jobs for Run-2 and Run-3 campaigns (2022, 2023, 2024) as long as we maintain the current campaign setup. This ensures that all sites remain actively engaged in ongoing data processing without requiring immediate hardware upgrades.

(3) Validation:

• Starting with CMSSW_15_0_0_pre1, we switch from v2 to v3 for validation and maintain validated v3 versions moving forward.
• The High-Level Trigger (HLT) will benefit from this by not needing to perform separate validation for v3, simplifying the validation process and reducing redundancy.