Hi Yehuda, Kyle, Based on previous discussions regarding Response for Bucket Creation by user which is already owned by him, I have come up with following scenario and proposed solution: We are trying to match RGW S3 responses with AWS S3 responses. AWS S3 gives/shows different responses/behaviors based on the region of location of bucket. For users of AWS S3 in region US Standard, 200 OK is desired or used to response but for users of other regions, 409 conflict is expected. We propose to provide configurable response via config_opts option where by we can configure our installation/set up to either give US Standard region response or other one. This we will be able to set up per region. By default, this will be set to current response. Let me know if above solution looks acceptable or if we can approach in any other way. We have looked into the issue from AWS region point of view. I agree we have valid points for keeping response same also but we see some merit in other response as well from use case point of view also along with making responses similar to other regions AWS S3 behavior. In any case, kindly let me know your views. Thanks On Wed, Jun 17, 2015 at 1:54 AM, Harshal Gupta <harshal.gupta001@xxxxxxxxx> wrote: > I understand here the major concern is for the clients who have > developed their apps keeping in mind 200 OK as the response in > duplicate bucket creation. However 409 can be useful in a scenario > which can be derived as below: > > A customer belonging to a company account creates a bucket and fill it with some > files. A colleague of his then tries to create a bucket with the same > name as above with the same keys which are shared by the employees of > that company or a team in particular. Now since he gets 200 OK, he > thinks the bucket is created anew and tries to use it to upload some > modified versions of the previously uploaded files in that bucket, for > his own use. Now the original files will be lost. > > In case if he gets 409, he will actually know that there may be some > data in the already created bucket and might check on it before > overriding it. > > Since Changing the response to 409 might cause a problem to the > existing customers, we can instead provide a option (boolean probably) > 'use_aws_standard_region_responses' which checks whether the region is > standard or different. Default can be true. Existing users can go with > true and we can give option to configure for new users. This flag > might as well used for fixing for other region based discrepancies in > AWS S3. > > Thanks, > > On Fri, Jun 12, 2015 at 5:21 AM, Yehuda Sadeh-Weinraub > <yehuda@xxxxxxxxxx> wrote: >> >> >> ----- Original Message ----- >>> From: "Kyle Bader" <kyle.bader@xxxxxxxxx> >>> To: "Yehuda Sadeh-Weinraub" <yehuda@xxxxxxxxxx> >>> Cc: "Harshal Gupta" <harshal.gupta001@xxxxxxxxx>, "ceph-devel" <ceph-devel@xxxxxxxxxxxxxxx> >>> Sent: Thursday, June 11, 2015 2:22:56 PM >>> Subject: Re: Duplicate bucket creation Response in RGW >>> >>> > I don't see a compelling reason why to change our current behaviour. The >>> > fact that Amazon itself is inconsistent makes me think that it just an >>> > artifact of their architecture, rather than a carefully designed api. >>> >>> Interesting.. if we look at the Amazon S3 FAQ we can understand the >>> differences in API responses: >>> >>> "Q: What data consistency model does Amazon S3 employ? >>> >>> Amazon S3 buckets in the US Standard region provide eventual >>> consistency. Amazon S3 buckets in all other regions provide >>> read-after-write consistency for PUTS of new objects and eventual >>> consistency for overwrite PUTS and DELETES." >>> >>> If we consider buckets in our implementation to be eventually >>> consistent, we should probably return 200. If we can provide >>> read-after-write consistency, then we should probably return 209. >>> >> >> Do they tie the different responses to the different consistency models in the different regions? We're strongly consistent, however, I still think that bucket creation should be idempotent. Impatient client applications tend to retry operations and end up with error responses that can be avoided. >> >> Yehuda > > > > -- > HARSHAL GUPTA > Software Engineer > KIWI Inc. -- HARSHAL GUPTA Software Engineer KIWI Inc. -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
