> > 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.
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 And also I have tried to change the s3 credentials and was able to write to a bucket and do a list operation. (Tested this on a non-secure cluster) Thanks, Bharat On Mon, Mar 2, 2020 at 12:44 AM Elek, Marton <[email protected]> wrote: > > 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] > >
