Routing multi cluster requests¶

Concept¶

The goal of federation is to present an interface that fuses multiple clusters into a single view.

This requires a router or proxy which determines which cluster(s) a request should go. This could exist in several places: entirely in the client, in a dedicated request router service, on the local cluster's API server.

For the purposes of this discussion, we'll consider how this works when implemented entirely on the client side. A router service is likely to have similar request handling behavior but has the additional requirement to act as a transparent API server proxy.

Examples¶

My "home cluster" is qr1hi. I have a token qr1hi-secretsecretsecret.

I want to read a collection on c97qk using the Python SDK.¶

c = CollectionReader("c97qk-...")

1. The CollectionReader calls the request router class.
2. The request router class examines the prefix c97qk and contacts c97qk.arvadosapi.com.
3. The request router uses the "salted" token hmac(c97qk, qr1hi-secretsecretsecret) → qr1hi-secretsecretc97qk
4. c97qk gets the token and notices the qr1hi prefix.
5. c97qk contacts qr1hi to determine if the token is valid and what user is associated with the token.
6. c97qk caches the token and sets current_user. The request proceeds as normal.
7. The request gets the response and returns it to CollectionReader.
   • manifest_text needs to be munged by either the c97qk or the request router to add the hint "+K@c97qk" so that blocks will be fetched from c97qk.

I want to search for a collection across clusters¶

c = router.collections().list(filters=[["name", "like", "sample-1234%"]]).execute()

1. The router has a "search list" of clusters (where does this come from??? maybe an attribute of the primary user account on qr1hi?)
2. The router sends the request to each cluster in parallel using federated identity / salted token described above.
3. The router gathers the results.
4. The router collates the results (will need to understand "order" option to do this properly)
5. Collated results are returned
6. Paging - ??? likely need to keep track of some state locally to be able to be able to issue correct follow-up requests to each cluster. Can have consistent ordering within a page but not across pages unless all pages are fetched first.

I want to create a collection on another cluster.¶

Provide "owner_uuid" of a project or group on a foreign cluster.

router.collections().create(body={"owner_uuid": "c97qk-...."}).execute()

1. The request router class examines the prefix c97qk and contacts c97qk.arvadosapi.com using federated identity / salted token described above .
2. The cluster determines if the user has write access to the group or project and validates the create request as normal.
3. The newly created record is returned.

No "owner_uuid" means creating the object on the "home" cluster.

I want to update an object on another cluster.¶

router.collections().update(uuid="c97qk-....", body={....}).execute()

1. The request router class examines the prefix c97qk and contacts c97qk.arvadosapi.com using federated identity / salted token described above .
2. The cluster determines if the user has write access to object and validates the update request as normal.
3. The updated record is returned.

I want to change the ownership of a remote object to a project on my home cluster.¶

The object is located on c97qk and currently owned by me, I'd like to make it owned by a project qr1hi-...

1. Route the "update" as described above to c97qk.
2. c97qk contacts qr1hi and asks if the user has write access to the project.
3. The object is updated and returned to the user

(This suggests I can only share things with groups on the same home cluster as me. hmm.)