From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yehuda Sadeh-Weinraub Subject: Re: Duplicate bucket creation Response in RGW Date: Thu, 11 Jun 2015 19:51:55 -0400 (EDT) Message-ID: <724456735.13364839.1434066715855.JavaMail.zimbra@redhat.com> References: <1875013920.12639009.1433959710332.JavaMail.zimbra@redhat.com> <1688384556.13183297.1434040012831.JavaMail.zimbra@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: Received: from mx6-phx2.redhat.com ([209.132.183.39]:43671 "EHLO mx6-phx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751850AbbFKXv5 (ORCPT ); Thu, 11 Jun 2015 19:51:57 -0400 In-Reply-To: Sender: ceph-devel-owner@vger.kernel.org List-ID: To: Kyle Bader Cc: Harshal Gupta , ceph-devel ----- Original Message ----- > From: "Kyle Bader" > To: "Yehuda Sadeh-Weinraub" > Cc: "Harshal Gupta" , "ceph-devel" > 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