[openstack-dev] [swift][swift3][s3] Keep containers unique among a cluster
me at not.mn
Mon May 14 20:55:42 UTC 2018
On 14 May 2018, at 13:43, Pete Zaitcev wrote:
> On Thu, 10 May 2018 20:07:03 +0800
> Yuxin Wang <wang.yuxin at ostorage.com.cn> wrote:
>> I'm working on a swift project. Our customer cares about S3
>> compatibility very much. I tested our swift cluster with
>> ceph/s3-tests and analyzed the failed cases. It turns out that lots
>> of the failed cases are related to unique container/bucket. But as we
>> know, containers are just unique in a tenant/project.
>> Do you have any ideas on how to do or maybe why not to do? I'd highly
>> appreciate any suggestions.
> I don't have a recipy, but here's a thought: try making all the
> that need the interoperability with S3 belong to the same Keystone
> As long as you do not give those accounts the owner role (one of those
> listed in operator_roles=), they will not be able to access each
> buckets (Swift containers). Unfortunately, I think they will not be
> to create any buckets either, but perhaps it's something that can be
> tweaked - for sure if you're willing to far enough to make new
> -- Pete
Pete's idea is interesting. The upstream Swift community has talked
about what it will take to support this sort of S3 compatibility, and
we've got some pretty good ideas. We'd love your help to implement
something. You can find us in #openstack-swift in freenode IRC.
As a general overview, swift3 (which has now been integrated into
Swift's repo as the "s3api" middleware) maps S3 buckets to a unique
(account, container) pair in Swift. This mapping is critical because the
Swift account plays a part in Swift's data placement algorithm. This
allows both you and I to both have an "images" container in the same
Swift cluster in our respective accounts. However, AWS doesn't have an
exposed "thing" that's analogous to the account. In order to fill in
this missing info, we have to map the S3 bucket name to the appropriate
(account, container) pair in Swift. Currently, the s3api middleware does
this by encoding the account name into the auth token. This way, when
you and I are each accessing our own "images" container as a bucket via
the S3 API, our requests go to the right place and do the right thing.
This mapping technique has a couple of significant limits. First, we
can't do the mapping without the token, so unauthenticated (ie public)
S3 API calls can never work. Second, bucket names are not unique. This
second issue may or may not be a bug. In your case, it's an issue, but
it may be of benefit to others. Either way, it's a difference from the
way S3 works.
In order to fix this, we need a new way to do the bucket->(account,
container) mapping. One idea is to have a key-value registry. There may
be other ways to solve this too, but it's not a trivial change. We'd
welcome your help in figuring out the right solution!
More information about the OpenStack-dev