Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 06:16
    dependabot[bot] review_requested #1633
  • 06:16
    dependabot[bot] review_requested #1633
  • 06:16
    dependabot[bot] labeled #1633
  • 06:16
    dependabot[bot] labeled #1633
  • 06:16
    dependabot[bot] review_requested #1633
  • 06:16
    dependabot[bot] opened #1633
  • Apr 09 14:02
    francescocarzaniga opened #1632
  • Apr 09 12:23
    aduffeck review_requested #1541
  • Apr 09 12:23
    aduffeck ready_for_review #1541
  • Apr 09 07:12
    labkode closed #1625
  • Apr 09 07:11
    labkode closed #1619
  • Apr 09 06:38
    labkode closed #1624
  • Apr 08 21:56
    mateusz-garlacz edited #1631
  • Apr 08 21:21
    C0rby synchronize #1629
  • Apr 08 21:20
    mateusz-garlacz opened #1631
  • Apr 08 20:35
    mateusz-garlacz opened #1630
  • Apr 08 20:32
    C0rby review_requested #1629
  • Apr 08 20:32
    C0rby review_requested #1629
  • Apr 08 20:31
    C0rby review_requested #1629
  • Apr 08 20:31
    C0rby opened #1629
Michael Barz
@micbar
@ishank011 Thanks for merging
Jörn Friedrich Dreyer
@butonic
@ishank011 @labkode can you rebase and merge cs3org/reva#1557 ? @wkloucek is on vacation...
Ishank Arora
@ishank011
@butonic I'll have to create another PR as I can't push to @wkloucek's fork. Is that fine?
Ishank Arora
@ishank011
Never mind
Jörn Friedrich Dreyer
@butonic
@thmour where are you with the cephfs driver?
@aduffeck and I might want to jump in and join the effort
Hugo Labrador
@labkode
@butonic the existing work is in this file: cs3org/reva#1209
However we discussed a couple of weeks ago to start a new implementation fresh using a client-server model rather than relying on the local mounted filesystem
Very much like we have done it for EOS
Happy to hear that you're also interested
The goal of out integration is to expose the contents of Manilla shares (from OpenStack) to end-users so they can access its content
This may differ if you only want to target the ocis layout (with nodes and its own hierarchy) as that model will not allow to expose existing contents as OCIS is the only one that understand the data layout
Jörn Friedrich Dreyer
@butonic
yes, both are interesting options with their own tradeoffs
how do you plan to look up paths by fileid?
did you investigate using inodes? afaict they are (currently) not being reassigned, but you need admin access to do an ceph daemon mds.lumus dump inode 1099511627777 to get a path
and it will only return one path for hardlinked inodes
which might be something we could live with
but there is another problem with regard to fileids. afaict oc10 renders the fileid string in propfind results as <instanceid><padded fileid> whereas in ocis the fileid is the base64 encoded storageid:opaqueid ...
Jörn Friedrich Dreyer
@butonic
that means that it is impossible to run oc10 and ocis in parallel (against the same oc10 db and storage driver with the owncloud driver reading from the db as well) because the fileids would still be different
Jörn Friedrich Dreyer
@butonic
we could use the db to look up the storageid in the database or a kv store, but that adds more services ... snomething I'd like to avoid.
but there is another scenario which might make this kind of lookup necessary: moving a user from one strage provider to another would also change the fileid ...
unless we keep the storageid for the stroage provider internal ... and only expose a storage spaceid ... which the storage registry could then route to a storage provider. it would be an m-to-1 mapping ... multiple storage spaces ar served by a storage provider. and we could change the storage provider / driver by moving the spaceid.
that does not solve the problem of migrating fileids from on storage driver to another ... but yeah ...
I need to chew on this ...
Ishank Arora
@ishank011

unless we keep the storageid for the stroage provider internal ... and only expose a storage spaceid ... which the storage registry could then route to a storage provider. it would be an m-to-1 mapping ... multiple storage spaces ar served by a storage provider. and we could change the storage provider / driver by moving the spaceid.

@butonic I added the concept of virtual views which does something similar to what you need I guess, combining responses from various storage providers, so essentially it translates to having multiple spaces in the same provider

It might serve as a starting point for what you're suggesting cs3org/reva#1570
Jörn Friedrich Dreyer
@butonic
hm that sounds more like aggregating the results of multiple storage providers into a single storage space, looking at https://github.com/cs3org/reva/pull/1570/files#diff-0d2961654453acb28ab32bc57e437cd52492efd9c76e2db3b49864e6322081a6R1180-R1189. What I propose could be considered to be the other way around: a storage provider serves multiple storage spaces. That is in fact what both storage providers, the one mounted at /home and the one mounted at /eos(or more generic /users) do. You can extend that to multiple storage providers for /home-{a-h}, /home-{i-r}, /home-{s-z} and their counterparts /eos/user/{a-h}, /eos/user/{i-r}, /eos/user/{s-z}. Ultimately, they both present the same files. Especially, when we move the /myshares out of /home. The storage provider for /home just jails the user into a subtree of /eos/users/<userid> or /users/<userid>.
I'll try to clarify further ...
Id based References should IMO not consist of storageid:opaqueid but storagespaceid:opaqueid. The registry decides which storage provider is responsible for a storagespaceid
GetHome woult return the storagespaceid ind the storage registry would return the address for the storage provider responsible for that storage space.
Obviously, the requests that the gateway makes to the storage provider then need to carry the storagespaceid so it can handle the request accordingly, as in relative to that storage space root (eg a users home, a project space, ...)
Jörn Friedrich Dreyer
@butonic
in fact I think the storageid in the reference should not carry the storageprovider id, but the storage space id.
This would also allow moving users from one storage provider to another, without having to change the reference id. because only the registry would know that a certain storage space is now served by a different storage provider.
@ishank011 ^
I'll try to clarify this in an adr ...
Alex Unger
@refs
@labkode @ishank011 can I pick your brains regarding the user management concept? We merged this ADR https://github.com/owncloud/ocis/blob/master/docs/ocis/adr/0003-external-user-management.md and just want to check that the concept aligns
6 replies
Ishank Arora
@ishank011
@refs definitely, I'll go through it and ask you any questions I might have
@butonic ah okay, makes sense. But this still won't solve your use case, right? (moving users across storage providers). Because it will only work for SPs with matching inodes. This consolidates requests to the same set of resources through a single service, which I think would be a good idea anyway
Alex Unger
@refs

@refs definitely, I'll go through it and ask you any questions I might have

Ace, thank you <3

Alex Unger
@refs
@ishank011 that should basically be the foundation ADR for the next step, which is building an Admin API: cs3org/cs3apis#52
Alex Unger
@refs
@ishank011 sorry about owncloud/ocis#1825 ! didn't pop in my radar sooner, sorry for that :(
1 reply
Andre Duffeck
@aduffeck
@ishank011 just a friendly reminder that cs3org/reva#1541 is currently still missing the according eos bits
Florian Schade
@fschade
@ishank011, can you please have a look to owncloud/web#4823 if it meets your requirements
Ishank Arora
@ishank011
Hi @aduffeck, the process isn't really straightforward in EOS. We use a workaround for specific requests. We'll coordinate with the EOS devs on how best to implement it. We can merge your PR in the meantime
@fschade the issue is solved by exposing complete paths to web instead of just the name of the file cs3org/reva#1605
But it is incompatible with OC10 I guess, so we might need to update some tests or set some sort of config to skip those particular tests.
The PR owncloud/web#4926 still won't solve redirections from the received shares tab because it'll look for paths in the logged-in user's namespace only (please correct me if I'm wrong)
Andre Duffeck
@aduffeck
@ishank011 alright, sounds good. I marked the pr as ready for review.
Florian Schade
@fschade
@ishank011 , thanks for your feedback. We discuss this next week when @kulmann is back.