use static storage registry in reva

[butonic]

Instead of using a dynamic space registry in reva we should prefix the spaceid with a storage id as described in https://owncloud.dev/extensions/storage/proposedchanges/#space-providers This will allow us to use a static storage registry to significantly reduce complexity. Or in other words: "to avoid a self inflicted complexity monster".

One drawback is that moving spaces between storages would cause a fileid rename. There are several strategies to deal with this: 1) if the old storage provider cooperates it can return a redirect / cs3 resource type reference to the new location. the gateway can then resend the request and cache the new responsible storage provider 2) the old static storage regfistry returns the wrong storage provider. the storage provider returns a not found. as a fallback, the gateway then queries a migration storage registry which koops a tally of the moved spaces and knows the new storage provider. 3) we let the redirect or not found response bubble up to the clients and they have to deal with a fileid change.

For GA we do not need to support moving spaces, yet. A parallel deployment should work. When admins want to move personal spaces to a new storage provider we will have to implement the fallback migration registry.

[butonic]

For now we will use a static registry which routes based on the cs3 reference storageid, where the storageid is composed of {storageproviderid}${spaceid}.

• The static registry has to split the storageid and route based on storageproviderid.
• the storageproviders have to split the storageid and route based on spaceid.

To reflect this in the CS3 api we can add a spaceid to the cs3 resourceid, which would make splitting the storageid obsolete. This can be done during the beta. It should happen before releasing v1 of the cs3apis.

cc @kobergj for Tuesday ;-)

[dragotin]

@butonic Can we close this?

[kobergj]

I suppose so since there is no action here since 2 years.