Thanks for writing this up Marton. I updated the doc to add a fourth problem:
> Ozone buckets created via the native object store interface are not
visible via the S3 gateway.
I don’t understand option 1. Does it mean that we will have at least one volume
per user? Also the access key is separate per user - so how do I grant another
user access to my volumes?
I like option 2. The notion of volumes already doesn’t work in the S3 world. We
also need to fix enumeration of volumes by users, this is not an S3 issue.
Thanks,
Arpit
> On Mar 16, 2020, at 1:32 AM, Elek, Marton <[email protected]> wrote:
>
>
> There are 4 options remains:
>
> https://hackmd.io/uqSYkmd8SXGAAjQx3sObQg?both
>
> I think 2 (use the same volume for all the s3 buckets) and 3 (use
> volume-bucket format for s3 bucket names) are both very limited. 3 means that
> we remove the support of volumes for the whole s3 world, half part of the
> Ozone.
>
> The remaining ones: 1 and 4
>
> 4: remove the volume from the path of o3fs/ofs and use the same url for both
> S3 and Hadoop File system. But keep the volume functionality (use it as an
> administrative group).
>
> I know it makes harder to disjoint namespaces but it 1). I don't know what is
> the exact plan about that one 2). It seems to be possible with caching volume
> -> bucket information on the clinet side
>
> 1: restrict the view of the buckets to one volume per AWS_SECRET_ACCESS_KEY.
> Slightly more clear, but still has some confusion as you might see two
> different content with the same bucket name but different secret.
>
> I prefer the solution 4 and 1 is my second preference.
>
> Is there any more arguments / concerns about the proposed solution (against 4
> or 1)
>
> Thanks,
> Marton
>
>
>
>
>
> On 3/3/20 6:08 PM, Elek, Marton wrote:
>>> This is not true, as we use only use access key id during the creation of
>>> s3 bucket to generate volume name from accessKeyID.
>>> For other requests like create/list/read key, the flow is
>>> 1. GetVolumeName(Bucket)
>>> 2.GetVolume(GetVolumeName(Bucket))
>>> 3.GetBucket
>> Got it, thanks to explain it. It's more confusing than I thought :-( Even if
>> a volume is defined for an ACCESS_KEY_ID, it's not guaranteed to be the
>> volume for a specific bucket (as it's used only to __create__ the buckets).
>> What do you think about defining the volume name for the ACCESS_KEY_ID as
>> the current namespace/context. Remove the mapping table at all and always
>> use the actual volume during **any* operation? (similar to the kubernetes
>> current context...)
>> I rewrote the document and added 4 options (unfortunately all of them are
>> painful...), including this one.
>> https://hackmd.io/uqSYkmd8SXGAAjQx3sObQg?both
>> Can you please add if you have more (and add pro/con to any of them if you
>> see...)
>> Thanks a lot,
>> Marton
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
