Pete Zaitcev writes: > 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. Thanks for clarifying, yeah I expected it would be difficult since `.` was allowed to be used in bucket names and you can't construct domain names with most other seperators, not a deal breaker :) > >> 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. Ah ok, the information is encoded in the token, so on making a bucket/container public we'll still access it at <host>/tenant:container/... location, rather than a /swift/tenant sort of url > > 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. I might be understanding this wrong, but since endpoints are an admin only thing (to create), are you suggesting something like a different region per tenant or so? Doesn't keystone returns the tenantid while authenticating (I could be wrong), in which case we somehow enforce that the tenant-id for a user created in rgw[1] if you're using keystone should match the ones used at openstack and check for the value of tenant-id returned by keystone when authenticating? [1]: this is still tricky, as we create users at runtime after first authentication with keystone iirc > > -- Pete -- Abhishek Lekshmanan SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- 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
