All of lore.kernel.org
 help / color / mirror / Atom feed
* Duplicate bucket creation Response in RGW
@ 2015-06-10 12:22 Harshal Gupta
  2015-06-10 18:08 ` Yehuda Sadeh-Weinraub
  0 siblings, 1 reply; 8+ messages in thread
From: Harshal Gupta @ 2015-06-10 12:22 UTC (permalink / raw)
  To: ceph-devel

Hi,

I was comparing response of S3 and Ceph RGW for when we try to create
a bucket which already exists for the same account.

S3 (non-default region) throws an error with:
HTTP response code : 409 Conflict
error code : BucketAlreadyOwnedByYou

but on the other hand ceph gives a 200 OK while keeping the original
bucket as it is.

I am thinking to match the functionality of Ceph RGW same as s3
(non-default regions), as the one given by S3 seems more appropriate.

For this, I have added a new error code "BucketAlreadyOwnedByYou"
which will be thrown in the above mentioned
case.

Please give your opinion about it.

Thanks

-- 
HARSHAL GUPTA

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Duplicate bucket creation Response in RGW
  2015-06-10 12:22 Duplicate bucket creation Response in RGW Harshal Gupta
@ 2015-06-10 18:08 ` Yehuda Sadeh-Weinraub
  2015-06-11 11:30   ` Harshal Gupta
  0 siblings, 1 reply; 8+ messages in thread
From: Yehuda Sadeh-Weinraub @ 2015-06-10 18:08 UTC (permalink / raw)
  To: Harshal Gupta; +Cc: ceph-devel


iirc we return 409 in case you're trying to recreate the bucket in a different region. I don't see why we should return it if the user tries to create it in the same region it exists in. Amazon does not return 409 if a bucket is recreated on their main region (where it already exists), so I'm not sure why there should be an inconsistency when dealing with other regions.

Yehuda

----- Original Message -----
> From: "Harshal Gupta" <harshal.gupta001@gmail.com>
> To: "ceph-devel" <ceph-devel@vger.kernel.org>
> Sent: Wednesday, June 10, 2015 5:22:51 AM
> Subject: Duplicate bucket creation Response in RGW
> 
> Hi,
> 
> I was comparing response of S3 and Ceph RGW for when we try to create
> a bucket which already exists for the same account.
> 
> S3 (non-default region) throws an error with:
> HTTP response code : 409 Conflict
> error code : BucketAlreadyOwnedByYou
> 
> but on the other hand ceph gives a 200 OK while keeping the original
> bucket as it is.
> 
> I am thinking to match the functionality of Ceph RGW same as s3
> (non-default regions), as the one given by S3 seems more appropriate.
> 
> For this, I have added a new error code "BucketAlreadyOwnedByYou"
> which will be thrown in the above mentioned
> case.
> 
> Please give your opinion about it.
> 
> Thanks
> 
> --
> HARSHAL GUPTA
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Duplicate bucket creation Response in RGW
  2015-06-10 18:08 ` Yehuda Sadeh-Weinraub
@ 2015-06-11 11:30   ` Harshal Gupta
  2015-06-11 16:26     ` Yehuda Sadeh-Weinraub
  0 siblings, 1 reply; 8+ messages in thread
From: Harshal Gupta @ 2015-06-11 11:30 UTC (permalink / raw)
  To: Yehuda Sadeh-Weinraub; +Cc: ceph-devel

Hi Yehuda,

Following were my findings after I have created two buckets
"my-bucket-test-in-main" in US-Standard and "my-bucket-test-in-eu" in
EU region.

1. AWS throws 409 conflict with error code "BucketAlreadyOwnedByYou"
when I try to recreate either of the two buckets in EU region.

2. Throws 200 OK for "my-bucket-test-in-main" and 409 Conflict for
"my-bucket-test-in-EU" when I try to recreate the buckets in
US-Standard region.

So we can say that except the US-Standard region,  in all the other
regions, it throws 409 whenever you try to recreate a bucket . Thus
US-Standard region is a special case.

Similar observations can be seen for Bucket name Restrictions, where
it is far more relaxed in US-Standard region. I was able to create
names as "test_.._main-by-me", in US-Standard region, which is clearly
non DNS-compliant and which AWS discourages, according to their bucket
names page.

So I think that we can try to implement these according to what AWS is
following for the non-standard regions. Similarly I am planning to do
the same for bucket name restrictions so that they are more
DNS-compliant and similar to what AWS follows in other regions.

Please let me know your opinion. I am referring from following pages
in AWS documentation:

1. http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html
2. http://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html

Thanks,
Harshal

On Wed, Jun 10, 2015 at 11:38 PM, Yehuda Sadeh-Weinraub
<yehuda@redhat.com> wrote:
>
> iirc we return 409 in case you're trying to recreate the bucket in a different region. I don't see why we should return it if the user tries to create it in the same region it exists in. Amazon does not return 409 if a bucket is recreated on their main region (where it already exists), so I'm not sure why there should be an inconsistency when dealing with other regions.
>
> Yehuda
>
> ----- Original Message -----
>> From: "Harshal Gupta" <harshal.gupta001@gmail.com>
>> To: "ceph-devel" <ceph-devel@vger.kernel.org>
>> Sent: Wednesday, June 10, 2015 5:22:51 AM
>> Subject: Duplicate bucket creation Response in RGW
>>
>> Hi,
>>
>> I was comparing response of S3 and Ceph RGW for when we try to create
>> a bucket which already exists for the same account.
>>
>> S3 (non-default region) throws an error with:
>> HTTP response code : 409 Conflict
>> error code : BucketAlreadyOwnedByYou
>>
>> but on the other hand ceph gives a 200 OK while keeping the original
>> bucket as it is.
>>
>> I am thinking to match the functionality of Ceph RGW same as s3
>> (non-default regions), as the one given by S3 seems more appropriate.
>>
>> For this, I have added a new error code "BucketAlreadyOwnedByYou"
>> which will be thrown in the above mentioned
>> case.
>>
>> Please give your opinion about it.
>>
>> Thanks
>>
>> --
>> HARSHAL GUPTA
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>



-- 
HARSHAL GUPTA
Software Engineer
KIWI Inc.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Duplicate bucket creation Response in RGW
  2015-06-11 11:30   ` Harshal Gupta
@ 2015-06-11 16:26     ` Yehuda Sadeh-Weinraub
  2015-06-11 21:22       ` Kyle Bader
  0 siblings, 1 reply; 8+ messages in thread
From: Yehuda Sadeh-Weinraub @ 2015-06-11 16:26 UTC (permalink / raw)
  To: Harshal Gupta; +Cc: ceph-devel

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.

Yehuda

----- Original Message -----
> From: "Harshal Gupta" <harshal.gupta001@gmail.com>
> To: "Yehuda Sadeh-Weinraub" <yehuda@redhat.com>
> Cc: "ceph-devel" <ceph-devel@vger.kernel.org>
> Sent: Thursday, June 11, 2015 4:30:08 AM
> Subject: Re: Duplicate bucket creation Response in RGW
> 
> Hi Yehuda,
> 
> Following were my findings after I have created two buckets
> "my-bucket-test-in-main" in US-Standard and "my-bucket-test-in-eu" in
> EU region.
> 
> 1. AWS throws 409 conflict with error code "BucketAlreadyOwnedByYou"
> when I try to recreate either of the two buckets in EU region.
> 
> 2. Throws 200 OK for "my-bucket-test-in-main" and 409 Conflict for
> "my-bucket-test-in-EU" when I try to recreate the buckets in
> US-Standard region.
> 
> So we can say that except the US-Standard region,  in all the other
> regions, it throws 409 whenever you try to recreate a bucket . Thus
> US-Standard region is a special case.
> 
> Similar observations can be seen for Bucket name Restrictions, where
> it is far more relaxed in US-Standard region. I was able to create
> names as "test_.._main-by-me", in US-Standard region, which is clearly
> non DNS-compliant and which AWS discourages, according to their bucket
> names page.
> 
> So I think that we can try to implement these according to what AWS is
> following for the non-standard regions. Similarly I am planning to do
> the same for bucket name restrictions so that they are more
> DNS-compliant and similar to what AWS follows in other regions.
> 
> Please let me know your opinion. I am referring from following pages
> in AWS documentation:
> 
> 1. http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html
> 2. http://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html
> 
> Thanks,
> Harshal
> 
> On Wed, Jun 10, 2015 at 11:38 PM, Yehuda Sadeh-Weinraub
> <yehuda@redhat.com> wrote:
> >
> > iirc we return 409 in case you're trying to recreate the bucket in a
> > different region. I don't see why we should return it if the user tries to
> > create it in the same region it exists in. Amazon does not return 409 if a
> > bucket is recreated on their main region (where it already exists), so I'm
> > not sure why there should be an inconsistency when dealing with other
> > regions.
> >
> > Yehuda
> >
> > ----- Original Message -----
> >> From: "Harshal Gupta" <harshal.gupta001@gmail.com>
> >> To: "ceph-devel" <ceph-devel@vger.kernel.org>
> >> Sent: Wednesday, June 10, 2015 5:22:51 AM
> >> Subject: Duplicate bucket creation Response in RGW
> >>
> >> Hi,
> >>
> >> I was comparing response of S3 and Ceph RGW for when we try to create
> >> a bucket which already exists for the same account.
> >>
> >> S3 (non-default region) throws an error with:
> >> HTTP response code : 409 Conflict
> >> error code : BucketAlreadyOwnedByYou
> >>
> >> but on the other hand ceph gives a 200 OK while keeping the original
> >> bucket as it is.
> >>
> >> I am thinking to match the functionality of Ceph RGW same as s3
> >> (non-default regions), as the one given by S3 seems more appropriate.
> >>
> >> For this, I have added a new error code "BucketAlreadyOwnedByYou"
> >> which will be thrown in the above mentioned
> >> case.
> >>
> >> Please give your opinion about it.
> >>
> >> Thanks
> >>
> >> --
> >> HARSHAL GUPTA
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>
> 
> 
> 
> --
> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Duplicate bucket creation Response in RGW
  2015-06-11 16:26     ` Yehuda Sadeh-Weinraub
@ 2015-06-11 21:22       ` Kyle Bader
  2015-06-11 23:51         ` Yehuda Sadeh-Weinraub
  0 siblings, 1 reply; 8+ messages in thread
From: Kyle Bader @ 2015-06-11 21:22 UTC (permalink / raw)
  To: Yehuda Sadeh-Weinraub; +Cc: Harshal Gupta, ceph-devel

> 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.

-- 

Kyle

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Duplicate bucket creation Response in RGW
  2015-06-11 21:22       ` Kyle Bader
@ 2015-06-11 23:51         ` Yehuda Sadeh-Weinraub
  2015-06-16 20:24           ` Harshal Gupta
  0 siblings, 1 reply; 8+ messages in thread
From: Yehuda Sadeh-Weinraub @ 2015-06-11 23:51 UTC (permalink / raw)
  To: Kyle Bader; +Cc: Harshal Gupta, ceph-devel



----- Original Message -----
> From: "Kyle Bader" <kyle.bader@gmail.com>
> To: "Yehuda Sadeh-Weinraub" <yehuda@redhat.com>
> Cc: "Harshal Gupta" <harshal.gupta001@gmail.com>, "ceph-devel" <ceph-devel@vger.kernel.org>
> 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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Duplicate bucket creation Response in RGW
  2015-06-11 23:51         ` Yehuda Sadeh-Weinraub
@ 2015-06-16 20:24           ` Harshal Gupta
  2015-06-18 16:50             ` Harshal Gupta
  0 siblings, 1 reply; 8+ messages in thread
From: Harshal Gupta @ 2015-06-16 20:24 UTC (permalink / raw)
  To: Yehuda Sadeh-Weinraub; +Cc: Kyle Bader, ceph-devel

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@redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Kyle Bader" <kyle.bader@gmail.com>
>> To: "Yehuda Sadeh-Weinraub" <yehuda@redhat.com>
>> Cc: "Harshal Gupta" <harshal.gupta001@gmail.com>, "ceph-devel" <ceph-devel@vger.kernel.org>
>> 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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Duplicate bucket creation Response in RGW
  2015-06-16 20:24           ` Harshal Gupta
@ 2015-06-18 16:50             ` Harshal Gupta
  0 siblings, 0 replies; 8+ messages in thread
From: Harshal Gupta @ 2015-06-18 16:50 UTC (permalink / raw)
  To: Yehuda Sadeh-Weinraub; +Cc: Kyle Bader, ceph-devel

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@gmail.com> 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@redhat.com> wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Kyle Bader" <kyle.bader@gmail.com>
>>> To: "Yehuda Sadeh-Weinraub" <yehuda@redhat.com>
>>> Cc: "Harshal Gupta" <harshal.gupta001@gmail.com>, "ceph-devel" <ceph-devel@vger.kernel.org>
>>> 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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2015-06-18 16:50 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-10 12:22 Duplicate bucket creation Response in RGW Harshal Gupta
2015-06-10 18:08 ` Yehuda Sadeh-Weinraub
2015-06-11 11:30   ` Harshal Gupta
2015-06-11 16:26     ` Yehuda Sadeh-Weinraub
2015-06-11 21:22       ` Kyle Bader
2015-06-11 23:51         ` Yehuda Sadeh-Weinraub
2015-06-16 20:24           ` Harshal Gupta
2015-06-18 16:50             ` Harshal Gupta

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.