CVMFS Sync Meeting

Friday 8 May 2026, 11:00 → 12:30 Europe/Zurich

31/S-023 (CERN)

11:00 → 11:10 Operational status & service overview

• Current CVMFS service health (repositories, stratum-0/1, monitoring)
• Any incidents since last meeting
• Short-term operational risks or alerts

Items on the table:

 

• Very smooth operation. The number of load/fatigue warnings from the S1 decreased dramatically, probably linked to our choice of doing passthroughs. Can be checked on filer-carbon.
  
  
  
  
  
• Dave asks to give to the new S1 frontend machines the same aliases as the previous ones (front-lcg-XX). At first it seems weird, however doing it will allow us to continue relying on their worldwide monitoring infrastructure, and correlate with past data
• Unsurprisingly I see that the services given by the ourproxy cluster are not well known by our IT community (CVMFS caching, CAProxy, Frontier)
• The migration of the S1 frontend is actually going very well, no incidents or hiccups reported
  
  ... I found this strange glitch in the monitoring of the S1 file descriptors. I have no explanation yet, and AFAIK nothing had happened at that time. Or not?

11:10 → 11:20 Issues & interventions follow-up

• Review of open issues
• Status of ongoing or planned interventions
• Decisions needed / actions agreed

11:20 → 11:30 Onboarding & knowledge transfer

• Onboarding progress for Hugo and Maria

• Open questions or unclear areas

• Documentation gaps or runbooks to improve

• Identify topics needing deeper walkthroughs (future sessions)

Items to review: 

• RQF3555480 (Hugo) Request new CVMFS repository
• RQF3639647 (Hugo) Request /eos/project-a to be mounted on cvmfs-ams
• RQF3619820 (Hugo) Reduce the auto tag timespan to 1 month for sw.hsf.org
• RQF3570904 (Maria) Request new CVMFS repository

11:30 → 11:40 Collaborator input – SFT / Valentin

• Updates from SFT side

• Cross-team dependencies or changes impacting CVMFS

• Technical discussions or requests for support

• Upcoming developments worth tracking

Status of the Elastic publishers: sft trying to think at it. It may be related to the more recent activity on the alibuild components

Hugo: let's create a small pilot cluster: one gateway serving ALL the repos, two publishers serving ALL repos
Fab: what about beingn able to publish without being forced to su to the cvms user?

Status of the releases
2.14 prerelease supports the automatic discovery of the gateway, still in test/evaluation phase

11:40 → 11:45 Planning & priorities

• Short-term priorities until next sync

• Upcoming milestones or expected changes

• Topics to follow up

11:45 → 11:50 AOB