Enhance storage registry with virtual views

[ishank011]

Why?

We want to consolidate user requests for references which can span across multiple storage providers. For example, we want to expose mounts such as /eos, /projects, /homes, /MyShares, /media when we get a PROPFIND to /. Currently, we try to find the longest prefix match in the storage registry rules and redirect the request to the corresponding storage provider. However, such root requests can't be handled by that as none of the registry rules would be a prefix of /.

Virtual views

For cases when we're unable to find a prefix match in the rules, we want to get all mounts that are encapsulated by the path in the user request. This would be simple to implement if we use global namespaces which have similar views for all the users. However, for special mounts such as /home and /MyShares, the internal paths are constructed based on the user in context and out of all the storage providers which handle these special mounts, we need to select the one corresponding to the logged-in user. The issues with this are explained via an example in the next section.

Current design

Let's say we have 5 EOS instances and the corresponding storage providers (for home instances, we have one SP for homes and the other a global SP)

• eos-home-00 (eos-home-00-home and eos-home-00-eos)
• eos-home-01 (eos-home-01-home and eos-home-01-eos)
• eos-home-02 (eos-home-02-home and eos-home-02-eos)
• eos-project (eos-project)
• eos-media (eos-media)

In the current design, with the home mapping /home-{{substr 0 1 .Username}},we'll have the following rules (assuming users are sharded alphabetically across the home instances)

• /home-{a-h} => eos-home-00-home
• /home-{i-r} => eos-home-01-home
• /home-{s-z} => eos-home-02-home
• /eos/user/{a-h} => eos-home-00-eos
• /eos/user/{i-r} => eos-home-01-eos
• /eos/user/{s-z} => eos-home-02-eos
• /eos/project => /eos/project
• /eos/media => /eos/media

Now, if we get a request ListContainer(/), even if we want to combine the responses from all these storage providers, it won't work for the home storage providers. For user alice, the /home-a mapping would work but when the call goes to /home-i, it will be redirected to eos-home-01 and the expanded path will be /eos/user/a/alice. But the instance eos-home-01 won't actually have this directory, causing it to fail.

New design

We will now have two tiers of abstractions in the storage registry service. For the special mounts, we move the logic from the gateway to the registry. The rules would look like:

• /eos/user/{a-h} => eos-home-00-eos
• /eos/user/{i-r} => eos-home-01-eos
• /eos/user/{s-z} => eos-home-02-eos
• /eos/project => /eos/project
• /eos/media => /eos/media
• /home [special mount]
  • /home-{a-h} => eos-home-00-home
  • /home-{i-r} => eos-home-01-home
  • /home-{s-z} => eos-home-02-home

So in the first layer, we'll only have rules which are exposed to the users, hiding the sharding logic in the registry. When alice sends a / request, in addition to the /eos mountpoints, the registry would return /home => eos-home-00-home. So we can assemble all the mounts accordingly.

Alternate design

One alternative can be to specify in the config what all mounts should be exposed in the root path, so if we have a config root_mount_points = /eos, /home, /myshares, we can call look for only the matching storage providers from the registry. We already have logic for handling /home requests, we'll need to add similar logic for /myshares. The disadvantages of this approach are:

• We'll need separate logic for each type of special mount (similar to https://github.com/cs3org/reva/blob/master/internal/grpc/services/gateway/storageprovider.go#L1910-L1928), which won't scale. With the multi-tiered storage registry, this is handled dynamically.
• The root mounts are not dynamic, but rather have to be specified in the config. A change in the mount points would involve changing this config as well.

In the implementation, we'll also fix #1143

cc @labkode

[labkode]

@ishank011 go for it