Federation implementation roadmap » History » Version 4
Tom Clegg, 08/08/2018 01:26 PM
| 1 | 1 | Tom Clegg | h1. Federation implementation roadmap |
|---|---|---|---|
| 2 | |||
| 3 | Use a remote-hosted workflow |
||
| 4 | |||
| 5 | * When retrieving a workflow record for arvados-cwl-runner, API server notices workflow UUID is remote, and fetches it with salted token (instead of looking in local DB) |
||
| 6 | |||
| 7 | 4 | Tom Clegg | Mount remote-hosted collection (read-only) in a container - [[Federated collections]] |
| 8 | 1 | Tom Clegg | |
| 9 | 4 | Tom Clegg | * (controller) fetch remote-hosted container by UUID (similar to workflow case) |
| 10 | * (controller) rewrite locators in manifest to indicate remote cluster |
||
| 11 | * (keepstore) if locator indicates remote cluster and data does not exist locally (or local signature is not supplied), fetch from remote using salted token |
||
| 12 | 3 | Peter Amstutz | * When creating a container to satisfy a CR, API searches for collection PDH in cr.mounts across federated nodes, and fetches it with salted token (instead of looking in local DB) |
| 13 | 1 | Tom Clegg | |
| 14 | Run some portions of a CWL workflow on a remote cluster |
||
| 15 | |||
| 16 | * When submitting container requests, a-c-r follows workflow/commandline/input UUID hints to choose a cluster |
||
| 17 | * Either a-c-r handles the multi-cluster stuff itself, or it submits CRs with "submit to cluster X" flag, and the API server acts as a proxy |