Open Stack

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 
> accounts
> that need the interoperability with S3 belong to the same Keystone 
> tenant.
> 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 
> other's
> buckets (Swift containers). Unfortunately, I think they will not be 
> able
> 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 
> middleware.
>
> -- 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!

--John