1. Multi VO Rucio
Andrew Lister

2. Overview Multi VO vision PR 1: RSE id (reviewed, needs patch)
PR 2: Internal representation for Account and Scope (to submit)
PR 3: Schema Change (future)
PR 4: VO enhancement (future) <- could be split up into 3 parts
Complications
Things I’ve found helpful
Summary

3. Multi VO Vision A consistent interface with the Single VO
Log in to a specific VO
From here on, as with Single VO (at REST/Client level)
A single codebase
No need to maintain two versions
New functionality is automatic
Dynamic admin at VO level
Add/Delete VOs at runtime

4. PR1: RSE id
Key Idea: Internal references to RSEs should be consistent.
Edits:
Make core level code use id consistently
Users should interact using the RSE name
Reason:
id will be unique across VOs
Core should be VO independent (where possible)

5. PR2: Internal Representations
Key Idea: Internal references to Accounts/Scope should be separated from external references.
Edits:
Make core level code use new types (InternalAccount, InternalScope)
Convert in API dir / calling funtion
Reason:
Cannot add new column to existing large tables (ATLAS)
Conversion function will allow easier addition of VO later
Gets raised if not converted

6. PR3 : Schema Change Key Idea: Accommodate Multi Vo in DataBase. Edits:
New VO table
New VO column in RSE table
Reason:
Need persistent storage of VOs

7. PR4: VO Enhancement Key Idea: Add VO to API. Edits:
Add VO to all Auth calls
Add VO to all methods in API directory
Add VO to daemons
Add logic to get VO from token when using REST
Check exceptional cases in Core (filters, etc.)
Enhance test scripts to cover new possibilities
Check for issues in config

8. PR4: VO Enhancement Cont. Reasons: Notes: Completes the Multi VO work…
All VO arguments will have default arguments which indicate single VO
Single VO tests must still pass without changing anything on this PR

9. Complications so far Issues with docker – fixed
Helps to be able to build a version in case you need to roll back
Large PR => Long review => Need for update
Dictionaries can be hard to track (_list_replicas!)
Tests coverage is not complete (Kronos) – ongoing
Testing can be awkward without running the full suite
2 sources of logs (/var/log/rucio/httpd_error_log, /var/log/httpd/error_log)
Certificates
Probes??

10. Things I’ve found helpful
Expose the MySQL port (3306?) and get a tool to view it:
DataGrip (free to use with academic )
Slack! Especially for on ramping
Martin/Mario - concepts and general questions
Hannes/Thomas - docker (Hannes seems to be only dev to use the docker)

11. Summary Lots to do! Only the final PR will make the behaviour differ
New complications every week (daemons, permissions, config, probes, ???)
Contacts in CERN dev team have been invaluable