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]
