Rucio Meeting

Thursday 2 Dec 2021, 15:00 → 16:00 Europe/Zurich

Martin Barisits (CERN)

15:00 → 15:05 News

• December release schedule
  • 1.27.0 released Tuesday!
    • 1.27.0.post1 due to non-grid trace issue in configuration
    • Beware of change of built-in names
      • type --> type_, filter --> filter_, etc.
      • Also affects some functions in clients
  • 1.26.10 LTS released on Monday
    • Fixes multihop regression with common FTS servers
  • 1.27.1 Dec-06
  • 1.27.2 Dec-13
  • 1.27.3 Jan-17
  • LTS
    • 1.23.18 Jan-10
    • 1.26.11 Jan-24
• Next week
  • Release plan for 2022 discussion
  • WebUI re-design first presentation/discussion/feedback collection
• Dec-16
  • 1.28 release roadmap planning

15:05 → 15:15 Community News & DevOps roundtable

• ATLAS
  • 1.27 release deployed
    • A few minor issues, nothing ground breaking
  • Enable SRM-HTTP compatibility
    • Rucio will schedule transfers in between SRM and HTTP/DAVS
      • Currently testing, not clear if successful
  • ARM Rucio clients for ATLAS (Local Rootbase)
• CMS
• Fermilab DUNE/Icarus/...
• Belle II
• MultiVO
  • Looking into 1.27 release deployment
• ESCAPE
  • Data Analysis Challenge 21 went well
  • Rules get stuck in Replicating
  • DAC21 lessons learned
    • Possibly presentation in 2022 in Rucio meeting
  • deleted_did table is not populated
    • Needs a configuration switch enabled
    • (Unless Oracle trigger is used)
• SKAO

15:15 → 15:25 Hot topics

15:25 → 15:45 1.27 release retrospecitve

Speaker: Martin Barisits (CERN)

Rucio 1.27 retrospective.pdf

Here is a quick summary of the action we decided to take (Please answer to this eMail if I forgot something): 

1. PR Review/Feedback process needs to be faster 

This is in a big part on me, but I also think there are a few other improvements we can try. Although everyone is encouraged to do review, people often do not feel comfortable to do so. One option we discussed could be to raise the review barrier to 2 approvals, which would take the pressure of responsibility off a single person to accidentally approve something faulty. This can obviously only work if this motivates people to actually do review. 

2. Tasks need to be more specific / big tasks need to be broken down 

Issues which are not specific/actionable are just not useful. "Improve something" kind of issues, without a specific list of what to improve should not exist on the tracker. Larger tasks should be broken down into sub-tasks. I will check if our current issue template is sufficient for this, but in general this will take discipline on us to take it to heart and create proper issues. 

3. Separate release priorities from long term priorities 

All issues/priorities on the roadmap should be actionable and achievable within the time-frame of the release. Long-Term priorities should not be part of it, only broken down sub-tasks of a long-term task should be included. 
We will track long-term priorities separate from the release. 

4. Make effort estimation part of the process 

We should make effort estimation a mandatory part of the process. This is to understand and properly track the effort going into development of the different tasks and should also help us to create more balanced release roadmaps. 

5. Prioritization 

This is not so much for the release roadmap, but in general clearer prioritization of which issues are more time-critical. 

7. Visualization and tracking progress 

I will introduce weekly burn charts again to visualize the progress we are making. This goes hand in hand with the effort estimations (4). 

More specific and not about the process in general: 

8. Plan the auditor rewrite 

9. Make a clear contributors guide for the probes 



Some of these actions we can implement right away, others will require a bit more thinking. I will work on this and come up with some suggestions. Please do not hesitate to contact me if you have ideas/

15:45 → 15:55 Developers roundtable

•  

15:55 → 16:00 AOB