On Wed, 20 Apr 2016 18:14:36 +0200 Abhishek Lekshmanan <abhishek@xxxxxxxx> wrote: > Are there any changes in the way bucket and object urls are used by > clients after creating a user with a tenant? My understanding so far has > been that the urls look the same for clients, and based on the > credentials passed in, we determine the tenant for requests. Is this > correct? Yes. > Also on making a bucket/object public the urls follow a format like: > `<host>/<tenant>:<bucket>` > > Is there an equivalent s3 vhost style url for the above? Trying any of > tenant.bucket.host combos mostly gave 404s No, sadly there is no such syntax. This is because a bucket name of "buc.ket" is valid, so there's no way to tell a cross-tenant reference in your proposal from a valid bucket name within a tenant. One has to continue using the old access method, like when using extended names of Virgina region buckets. > And similarly for swift making a bucket public, the only url that seemed > accessible was the above mentioned `<host>/<tenant>:<bucket>` format and > there is no swift url of the format > `<host>/swift/v1/<tenant>/<container>` etc? Is this also the expected > behaviour? Historically, we did not have the ability to do this, because, unlike traditional Swift, our URLs did not have a tenant in them. E.g. it was just /swift/v1/<container>. In Jewel, the tenant is included. It was made fully backwards compatible by saving the bit to signify the tenant-included URL into the token (the "rgwts" token). So now the cross-tenant access is done in the exactly the same way as in OpenStack Swift. One problem remains, as you can guess: cross-tenant access while authenticated with Keystone. This is simply not implemented. We considered a couple of approaches, such as - a special syntax, such as backslash "tenant\bucket" - a new header "X-RGW-Tenant" - a user attribute in Keystone (requires cooperation from Keystone) - a separate endpoint in the Keystone catalog, possibly using regions Thanks for raising this issue. Honestly I gave up on finding an elegant solution for now, although tinkering with endpoints seems like a winner. I think Radoslaw liked it too. If you have ideas, by all means please propose them. -- Pete -- 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
