Multi VO Rucio Andrew Lister

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

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

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)

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

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

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

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

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??

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

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