Thank you the feedback, Bharat.
> One approach I can think of is, we can move the volume generation also to
> secret generation and print the volume name for that user along with
> accessKey and access Secret, in this way volume name will be known to the
> user during secret generation. (but only issue is this command needs
to be
> supported in non-secure also) This can be done with very less code
changes.
Yes, I agree. We can print out the used volume during the secret creation.
But just adding this printing doesn't solve the confusion IMHO (See my
arguments below).
> For volume name generation, instead of (s3+md5hex(lowecAccesskey), we can
> replace all special characters not allowed in volume with "-" which
is more
> readable than the current approach.
> Please let me know your thoughts.
I would prefer to use a map instead of the hard coded rule between the
access_key_id -> volume. If you use any user based transformation rules
(with or without the md5hex) you can't share the same s3 bucket between
two users.
Let's say you have one user who writes to an s3 bucket and an other user
reads it. If the volume name is generated from the user name they
couldn't use the same bucket.
My only improvement in this proposal is to define this mapping manually
(which volume should be used?) for each the access_key_id.
(And for technical reasons, it seems to be easier to do this with
supporting multiple access_key_id to the same user, which is already
supported by AWS).
Marton
On 3/2/20 8:20 AM, Bharat Viswanadham wrote:
Thank You, Marton, for starting this discussion and detailed proposal.
I have few comments, commented on the document and also have another
proposal that can be done with minimal code changes and also can avoid the
confusion of knowing what is the volume name needs to be used during O3fs.
One approach I can think of is, we can move the volume generation also to
secret generation and print the volume name for that user along with
accessKey and access Secret, in this way volume name will be known to the
user during secret generation. (but only issue is this command needs to be
supported in non-secure also) This can be done with very less code changes.
(Proposal also needs this command to be supported in the secure cluster
For volume name generation, instead of (s3+md5hex(lowecAccesskey), we can
replace all special characters not allowed in volume with "-" which is more
readable than the current approach.
Please let me know your thoughts.
Thanks,
Bharat
On Fri, Feb 28, 2020 at 11:43 AM Arpit Agarwal
<[email protected]> wrote:
You can sign in with Cloudera Google account and comment.
On Feb 28, 2020, at 11:42 AM, Jitendra Pandey
<[email protected]> wrote:
Thanks for starting this thread Marton. We need to address this for
better
usability.
How do I comment on the document? Do I need Hackmd account?
On Fri, Feb 28, 2020 at 5:47 AM Elek, Marton <[email protected]> wrote:
Hi,
We had multiple discussions earlier about simplifying s3_bucket ->
ozone_volume/ozone_bucket mapping (or at least make it more opaque)
I wrote a formal proposal about a very lightweight change:
https://hackmd.io/uqSYkmd8SXGAAjQx3sObQg?view
Please let me know what do you think...
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]
