General information


Middleware


UMD

About the new Linux distribution

About UMD

  • collecting the products available on EL9 to prepare the first UMD5 release

Operations

ARGO/SAM

FedCloud

  • EGI Check-in migration from MitreID to Keycloak:
    • two cases are pursued individually, with minimal or no impact
    • full tickets list

Feedback from DMSU


New Known Error Database (KEDB)

The KEDB has been moved to Jira+Confluence: https://confluence.egi.eu/display/EGIKEDB/EGI+Federation+KEDB+Home

  • problems are tracked with Jira tickets to better follow-up their evoulution
  • problems can be registered by DMSU staff and EGI Operations team

Monthly Availability/Reliability

Under-performed sites in the past A/R reports with issues not yet fixed:


Under-performed sites after 3 consecutive months, under-performed NGIs, QoS violations: (Jan 2023):

sites suspended: 

Documentation

IPv6 readiness plans

Transition from X509 to federated identities (AARC profile token)

  • In Feb 2022 OSG fully moved to token-based AAI, abandoning X509 certificates
  • HTCondorCE: replacement of Grid Community Toolkit
    • The long-term support series (9.0.x) from the CHTC repositories will support X509/VOMS authentication until May 2023
    • Starting in 9.3.0 (released in October 2021), the HTCondor feature releases does NOT contain this support
    • EGI sites are recommended to stay with the long-term support series for the time being

Migration of the VOs from VOMS to Check-in

  • transition period where both X509 and tokens can be used
    • delays in updating the GRID elements to the latest version compliant with tokens
    • not all of the middleware products can be compliant with tokens at the same time
    • the same VO has to interact with element supporting different authentications

Testing HTCondorCE and AARC Profile token

  • INFN-T1 did some tests with the AARC Profile token using its HTCondorCE endpoints
  • dteam VO registered in Check-in/Comanage:
    • Entitlements:
      • urn:mace:egi.eu:group:dteam:role=member#aai.egi.eu
      • urn:mace:egi.eu:group:dteam:role=vm_operator#aai.egi.eu
  • The HTCondorCE expects to find in the token the scope claim to authorise the jobs submission
    • in that moment Check-in didn't release this claim: it does since the migration to Keykloak technology replacing MitreID

WLCG Campaign

Hackathon events

  • 15th - 16th September ARC/HTCondor CE Hackathon, organised by WLCG, with HTCondorCE and ARC-CE to mostly investigating data staging issues (see GDB introduction)
    • agreed to enable the support of the several token profiles through plugins
      • same plugin for the several CEs 
      • plugins provided by the "creators" of the token profiles
    • CE teams to provide specifics to the AAI teams and to release a new CE version supporting the plugins

Plans for the coming months:

  • ARC-CE and HTCondorCE implemented a new API interface
  • The Check-in team is working on a plugin for the Check-in/AARC token profile allowing the authz on the CE side
    • according to the AARC guidelines, the claim to authorise the job submission is provided through a different attributes than the one used by the WLCG token
    • the plugin will translate the attribute to be understandable to the CEs
  • The plugin will be tested in production before its release in UMD
  • Then we can start the decommission procedure for the HTCondorCE long-term support series (9.0.x)
    • ideally before May 2023
  • At the same time the VOs using voms will be cloned to Check-in in order to be ready to use the tokens when the first HTCondor 10.0.x endpoints are in productions (some of the VOs might be involved in testing tokens with the 9.0.x version)

DPM Decommission and migration

  • DPM supported until June 2023
  • Sites are encouraged to start the migration to a different storage element since the process will take time
    • choosing the new storage solution depends on the expertise/experience of the sites and on the needs of the supported VOs 
  • See the slides presented by Petr Vokac at the EGI Conference 2022 about the migration tools to dCache
  • DPM provides a migration script to dCache (migration guide)
    • Transparent migration
      • Migrate just catalog (database) and keep files untouched
      • both SE store files on posix filesystem
  • Migration in three steps
    • verify the DPM data consistency
      • no downtime needed
      • the operation can last several days or some weeks
    • DPM dump and dCache import
      • downtime lasting about 1 day
  • In September opened tickets to the sites to plan the migration and decommission:
    • tickets list (9 out of 55 were solved)
    • Please let us know your plans for DPM EOL and in case you decide to use dCache migration tools the tickets will be used to support you on this storage migration method.
    • dCache migration should be done by June 2023

Planned completion date

By 2022

1

Beginning of 2023

5

By Feb 2023

5

By Q1 2023

8

By Q2 2023

11

undefined

12

Chosen technology

Migration to dCache

28

Migration to EOS

6

Migration to xroot/ceph

3

Migration to XrootD

1

Migration to Xcache

1

Migration to Dynafed

2

Not yet decided/no clear plan

11

Decommissioning SE or site

3

New benchmark replacing HEP-SPEC06

The benchmark HEPSCORE is going to replace the old Hep-Spec06

Main points agreed:

  • Existing resources at the sites will not be re-benchmarked with HEPscore (unless the site has modern resources and would like to re-benchmark them in order to get higher consumption in the accounting reports)
  • New resources purchased by the site will be benchmarked with HEPscore
  • HEPscore will be normalized with HS06 with factor 1
  • The switch to HEPscore in the accounting reports will happen on the 1st of April 2023 (when WLCG switch yearly pledges)
  • This implies that two benchmarks will co-exist on the infrastructure for quite some time
  • We would like to follow the progress regarding amount of the resources benchmarked with HEPscore
  • No need for reporting of measurements for two benchmarks in parallel for the same set of resources
    • This implies that accounting record should contain one metric for a single benchmark and benchmark name has to be properly defined in the accounting record.

Plans for the coming months:

  • A new APEL version compliant with the new benchmark will be released
  • Planned some tests in particular with sites sending normalised reports
  • Change of units: in the Accounting Portal all of the references to HepSpec06 will be replaced with the new benchmark
    • this will be implemented during last week of March
  • Need to distinguish between the resources benchmarked with one benchmark or the other to monitor the move to the new benchmark over the time
    • The accounting records will be tagged with the name of the benchmark used for normalisation
    • A new APEL version is going to introduce this feature
    • The Accounting Portal will allow to see the split of the resources by benchmark
    • This change can be introduced a couple of months after April

HEPSCORE application:

AOB


Next meeting

March

  • No labels