-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Storage Space semantics in the CS3APIs #3693
Comments
Comments from ocisBoth CERN and ownCloud decided together the following scheme: A resourceID contains either:
II was returning an absolute path in reva master. This is changed in the edge branch. A stat, like on the filesystem has no knowledge about the path, only the file basename. We know and return the parentID. The full path can be queried with Examples from @labkode
Comments on the desired request/responses
We thought that we had a mutual agreement that the spaces are first class citizens and all paths are relative to a space.
Let us elaborate on this. You know the id of Now, after two request you are able to do all kind of operations within the whole depth of this tree. We never encounter cases in where clients need to do the example
Summary
@dragotin Please also add your thoughts, because you were always insisting on that level of indirection with the clients in mind. |
I agree what is written in the summary above. That is IMHO a good summary of what spaces are about. It is important to note that - from a clients POV - it is always needed to query the list of available spaces first, to know the space IDs. That is needed because clients should be able to organize the spaces according the abilities of the platform of the client. For example, a desktop client will put the different types of spaces to different places than the web client. With the spaces, there is no absolute file tree of all files any more by default. @labkode what is the actual problem that you need to solve? Can we look into it together? |
IMO there is no way around making clients smarter aka teaching them how to discover spaces so they can work in with a truly federated storage API. For that the cleanest approach is to always require a relative CS3 Reference in requests. That being said we obviously need backwards compatability:
We could define levels for CS3 clients to indicate that a client
|
The problem we're trying to solve is to implement the expected behaviour of spaces on the edge branch for EOS and I have to admit that we're struggling . Would be possible to express the semantics of how spaces should behave on the CS3APIs documentation? Currently the information is spread across CS3APIS, codebase, GH issues and ADRs. @micbar Thank you for the explanation, that is indeed better than our initial assumptions, however we still have some doubts.
The more I think about it the more I think that having a [1] https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.StorageSpace |
@labkode thanks for the answer!
That is unfortunate, I offer any help possible. After the first beta next week, our resources are not so streched anymore.
Yes! But specially after this discussion in this ticket i have more and more the feeling that we are already 90% alingned and need to overcome the last 10% to get cernbox running and performant on the edge branch. That is still one of our most important missions. To make things better, we will provide a proposal for the cs3 api changes in form of a PR next week. Another project from @wkloucek and me is the https://github.com/owncloud/cs3api-validator/ project which is now also available as a docker image. We have it running on reva and ocis CI already. API spec, documentation and this testSuite can provide a good start for a better developer experiance.
Yes let us follow up on that. It is already on our agenda during the beta phase. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions. |
Needs documentation and tests about final outcome. |
This writeup comes from a deep investigation performed by @ishank011 @gmgigi96 @glpatcern as part of our activity to run OCIS edge branch at CERN.
Examples on edge branch running ocisfs
4c510ada-c86b-4815-8820-42cdf82c3d51
-> / is the home space ID254d0b60-20e4-4340-9eae-6fa9103ae7d7
-> /app-try7321538e-15da-4352-8dd7-d59b3319e7ef
-> /app-try/app-new-try.txtExpected desired behaviour
The comment about semantics of
path
field will need to be amended:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceInfo
Conclusion
Firstly, examples A and G show a defective implementation that doesn't honour the CS3APIs. Paths are a first class citizen of the API and are expected to work.
Secondly, the current implementation in
ocisfs
is poorly designed with potential nefarious consequences for clients.Simply put, clients will need to have memory and and traversing trees will not be performant.
For example, having the tree
/a/b/c/d
a client that works with paths can query/a
,/a/b
or/a/b/c
.A client that works with ids and that knows about
d
will need to query the parent ofd
, which isc
, then the parent ofc
which isb
and then the parent ofb
which isa
. Performance will be a function of tree depth. A workaround you may suggest is to "remember" node information in the client, however this pushes complexity to any client using the API (desktop sync, mobile) and basically anyone willing to integrate with OCIS in an optimal way.To illustrate this behaviour from UNIX/POSIX environment, we're inside folder
/var/tmp/data/log/2022/05/03/proxy
.In your case to go to:
/var
folder you need to do:By path you do:
@butonic @micbar @dragotin
The text was updated successfully, but these errors were encountered: