Dops – 27/08/2026
At CERN: Federico, Alexandre, Chistopher, Yan, Juraj, Alan, Ryunosuke, Andrea
On Zoom: Andrei, Mazen, Luisa, Loris, Jorge, Daniela, Héloise, Ueda, Janusz, Bertrand, Dhiraj, Xiaomei, Stella, Nattthan, Marco, Hideki, Ueda
Apologies:
this meeting is being recorded
Previous meetings + follow-ups
- Last Dops June 18th! Follow-ups:
- Federico (long time ago) sent out a google form for collecting requirements for DiracX Transformation/Production system
- Federico asked installations to report on progress in moving to DIRAC v9
- Belle2 answer: work ongoing, maybe update at Q1/27
- GridPP (informally): Q1/2027
Communities issues and requests : roundtable
LHCb:
Federico+Christopher+Christophe+Alexandre+Ryun
- Running in production the latest releases of everything
Belle2
Ueda, Hideki
Juno+BES3:
Xiaomei
- No issues about operation
- k8 setup ready for DiracX, and also OpenSearch and S3
- fromPreviousMeeting
monitorFiles not working correctly for production transformations. Maybe buggy,
- Federico+Chris in LHCb a different mechanism is used
- Luisa in CTAO also a different solution
- 20th May Andrei found a bug, hot-fixed, will commit if tested OK
EGI+IN2P3
Andrei, Mazen
- working smoothly in summer
- Migration to v9 prob Q1/2027
- GreenDIGIT result to be presented in September
CTAO
Natthan, Loris, Stella
- Max opened few DIRAC issues
CLIC(+FCC)
André, Juraj
- Migration to v9: meet every other week. v9 server set-up, DiracX running in paas.cern.ch
CMS
Alan, Andrea, Marco
- Interest in understanding why DiracX needs S3 and what are the use-cases. Specifically, we are interested in understanding if seaweedfs could be replaced it by other S3-like technologies
- Marco made a very first PoC for submitting HTCondor jobs based on the DiracX dummy job executor developed during the hackathon:
- We set a CMS installation for Dirac in one of our VMs at CERN:
- We also set a k8s-based CMS DiracX area:
- If interested, we can share more details and documentation
GridPP:
Daniela, Simon, Janusz
- No news in prod: v8.0.80
- Simon and his AI agents continue in his quest to make DIRAC secure in the face of AI enabled threats
- Unfortunately no time to look at upgrade to v9, but to answer (one) of Federico’s questions: The blocker was the long-term support release, which has been resolved, but we currently are swamped by more urgent issues^{TM}
Releases announcements and reviews
DiracOS
DIRAC
reminder for multi-branch support if a PR needs to be applied to more than 1 branch, it is responsibility of the developers to create all of them. Only at that time they will be merged.
DiracX
- v0.3.0
- add rss router serving cached resource status (#940) (d214f90)
- core: add AsyncCacheableSource and cacheable-source wiring (#938) (8b944bf)
- db: bulk all-VO read queries for ResourceStatusDB (#939) (cf16090)
CWL
DiracX-web
- first non-alpha release ?
Pilot
interCEde
Agenting and AI developments
Feature requests, and developers’ issues: inputs and prioritizations from communities
Report from Yan
Yan internship will end in few weeks. Report presented, and attached to the agenda.
Main points:
- The exploration made good progress. At the same time the given performance goals have not been met, even when using directly Lua scripts for interacting with Redis. Some ideas not yet explored.
- There are 2 weeks left in Yan’s internship to complete the last points and produce something that can be assigned to someone else
Answers to questions:
- this is pure Redis, no need for extensions, can also be run in valkey. Not a new tool.
- multi-VO case should “just work”
- There should be no locks needed, as Redis is inherently sequential
- There are no explicit task queues, but the grouping with keys in Redis is a “sort of” task queue
Transformation/Production “system” in DiracX
- So far, received 6 responses in the form from: Belle2, ILC, CMS, GridPP, Juno+CEPC+BESIII, Rubin (!)
- missing CTAO, LHCb (!), FCC, EGI (?)
- Extreme summary points for here, rest will be integrated for the ADR
- Everyone needs one, mostly already using one
- developed inside and outside of DIRAC
- MC is the one use case common to everyone
- Everyone uses CVMFS for SW distribution
- Everyone seems to have similar operational models, with few core experts
- the “Analysis Production” model is also present
- Pain points also rather similar (debugging TS specific issues is “hard”)
- What current TS does not provide:
- “forks&joins” in the workflows
- TS-specific analytics not possible directly
- Workflows validation (which are sometimes added in extensions)
- well defined interface with metadata systems, which are always cited
- AI assistant requested (not only for debugging)
ADR: waiting for few details to iron before publishing it (in a PR). ETA: end of next week
AOB
Next appointments
