RGW and Keystone

RGW and Keystone

[Chmouel Boudjnah]

Hello Florian,

I was wondering how the Keystone integration with ceph, I have been
reading the documentation of the way it shows how to configure the
keystone endpoints here :

http://ceph.com/docs/next/radosgw/config/

and I don't see how the part :

keystone endpoint-create --service-id <id> --publicurl
http://radosgw.example.com/swift/v1 \
        --internalurl http://radosgw.example.com/swift/v1 --adminurl
http://radosgw.example.com/swift/v1

would work with multiple tenancies since user a or user b putting an
object called bar in container foo would always end up with the same
URL like :

http://radosgw.example.com/swift/v1/foo/bar

The way we do that in Swift is to have in keystone this type of URL :

 --publicurl 'http://192.168.206.130:8888/v1/AUTH_%(tenant_id)s' \

and the keystoneauth make sure the token validated match the
%(tenant_id) in URL, i.e:

https://github.com/openstack/swift/blob/master/swift/common/middleware/keystoneauth.py#L204

am I totally off track or the keystone support support only a single tenant?

digging into the code I don't see any trickeries to make this works
properly it just check for the roles assigned to the user/tenant
matching the configuration (which is good) but don't do much more
after that :

https://github.com/ceph/ceph/blob/master/src/rgw/rgw_swift.cc#L500

Let me know what do you think.

Cheers,
Chmouel.

Re: RGW and Keystone

[Yehuda Sadeh]

(resending due to formatting)

I'm not Florian, but I think I can help here.

The radosgw user-tenant model is (currently) different from the swift
one. It's more like the S3 model, where users live in a single
namespace. So the current Swift user mapping is not perfect. We
created 'subusers' to emulate that, but in the end all accounts reside
under the same tenant (in the swift jargon).
That been said, I've prototyped a real multi-tenancy solution not too
long ago that will encapsulate both the swift and the S3 user cases
(wip-5073-2 for the brave ones). It might still be missing some
pieces, but most of it is there. I also have a new blueprint on my
to-do list.

Yehuda

On Tue, Jun 4, 2013 at 2:44 AM, Chmouel Boudjnah <chmouel@enovance.com> wrote:
> Hello Florian,
>
> I was wondering how the Keystone integration with ceph, I have been
> reading the documentation of the way it shows how to configure the
> keystone endpoints here :
>
> http://ceph.com/docs/next/radosgw/config/
>
> and I don't see how the part :
>
> keystone endpoint-create --service-id <id> --publicurl
> http://radosgw.example.com/swift/v1 \
>         --internalurl http://radosgw.example.com/swift/v1 --adminurl
> http://radosgw.example.com/swift/v1
>
> would work with multiple tenancies since user a or user b putting an
> object called bar in container foo would always end up with the same
> URL like :
>
> http://radosgw.example.com/swift/v1/foo/bar
>
> The way we do that in Swift is to have in keystone this type of URL :
>
>  --publicurl 'http://192.168.206.130:8888/v1/AUTH_%(tenant_id)s' \
>
> and the keystoneauth make sure the token validated match the
> %(tenant_id) in URL, i.e:
>
> https://github.com/openstack/swift/blob/master/swift/common/middleware/keystoneauth.py#L204
>
> am I totally off track or the keystone support support only a single tenant?
>
> digging into the code I don't see any trickeries to make this works
> properly it just check for the roles assigned to the user/tenant
> matching the configuration (which is good) but don't do much more
> after that :
>
> https://github.com/ceph/ceph/blob/master/src/rgw/rgw_swift.cc#L500
>
> Let me know what do you think.
>
> Cheers,
> Chmouel.
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RGW and Keystone

[Chmouel Boudjnah]

Hello Yehuda,

Sorry this was actually directed to you (florian actually told me you were the go to person for row).

I am not totally familiar with s3  how does a single namespace ensure a accounts/user don't have access to the resource of the others ?

Glad to know you are tackling the multi-tenancy for swift/s3, let me know if i can help for reviews.

Thanks,
Chmouel.


On 4 Jun 2013, at 17:04, Yehuda Sadeh <yehuda@inktank.com> wrote:

> (resending due to formatting)
> 
> I'm not Florian, but I think I can help here.
> 
> The radosgw user-tenant model is (currently) different from the swift
> one. It's more like the S3 model, where users live in a single
> namespace. So the current Swift user mapping is not perfect. We
> created 'subusers' to emulate that, but in the end all accounts reside
> under the same tenant (in the swift jargon).
> That been said, I've prototyped a real multi-tenancy solution not too
> long ago that will encapsulate both the swift and the S3 user cases
> (wip-5073-2 for the brave ones). It might still be missing some
> pieces, but most of it is there. I also have a new blueprint on my
> to-do list.
> 
> Yehuda
> 
> On Tue, Jun 4, 2013 at 2:44 AM, Chmouel Boudjnah <chmouel@enovance.com> wrote:
>> Hello Florian,
>> 
>> I was wondering how the Keystone integration with ceph, I have been
>> reading the documentation of the way it shows how to configure the
>> keystone endpoints here :
>> 
>> http://ceph.com/docs/next/radosgw/config/
>> 
>> and I don't see how the part :
>> 
>> keystone endpoint-create --service-id <id> --publicurl
>> http://radosgw.example.com/swift/v1 \
>>        --internalurl http://radosgw.example.com/swift/v1 --adminurl
>> http://radosgw.example.com/swift/v1
>> 
>> would work with multiple tenancies since user a or user b putting an
>> object called bar in container foo would always end up with the same
>> URL like :
>> 
>> http://radosgw.example.com/swift/v1/foo/bar
>> 
>> The way we do that in Swift is to have in keystone this type of URL :
>> 
>> --publicurl 'http://192.168.206.130:8888/v1/AUTH_%(tenant_id)s' \
>> 
>> and the keystoneauth make sure the token validated match the
>> %(tenant_id) in URL, i.e:
>> 
>> https://github.com/openstack/swift/blob/master/swift/common/middleware/keystoneauth.py#L204
>> 
>> am I totally off track or the keystone support support only a single tenant?
>> 
>> digging into the code I don't see any trickeries to make this works
>> properly it just check for the roles assigned to the user/tenant
>> matching the configuration (which is good) but don't do much more
>> after that :
>> 
>> https://github.com/ceph/ceph/blob/master/src/rgw/rgw_swift.cc#L500
>> 
>> Let me know what do you think.
>> 
>> Cheers,
>> Chmouel.
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RGW and Keystone

[Edward Hope-Morley]

Hi guys, I'm having the following issue with the RGW swift API:

The docs at http://ceph.com/docs/next/radosgw/swift/serviceops say that
for a GET request to list account contents I should do (as with Swift):

GET /{api version}/{account} HTTP/1.1


but, if I put the account RGW treats this as a bucket.

So the following works fine:

curl -i http://192.168.1.201:80/swift/v1 -X GET -H "X-Auth-Token: $token"

But this does not:

Re: RGW and Keystone

[Edward Hope-Morley]

Apologies, premature send ;)

On 19/06/13 11:00, Edward Hope-Morley wrote:
> Hi guys, I'm having the following issue with the RGW swift API:
>
> The docs at http://ceph.com/docs/next/radosgw/swift/serviceops say that
> for a GET request to list account contents I should do (as with Swift):
>
> GET /{api version}/{account} HTTP/1.1
>
>
> but, if I put the account RGW treats this as a bucket.
>
> So the following works fine:
>
> curl -i http://192.168.1.201:80/swift/v1 -X GET -H "X-Auth-Token: $token"
>
> But this does not:

curl -i http://192.168.1.201:80/swift/v1/$account -X GET -H
"X-Auth-Token: $token"

Am I doing something wrong or is this an anomaly in the RGW API?

Ed.

> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RGW and Keystone

[Yehuda Sadeh]

On Wed, Jun 19, 2013 at 3:03 AM, Edward Hope-Morley
<opentastic@gmail.com> wrote:
> Apologies, premature send ;)
>
> On 19/06/13 11:00, Edward Hope-Morley wrote:
>> Hi guys, I'm having the following issue with the RGW swift API:
>>
>> The docs at http://ceph.com/docs/next/radosgw/swift/serviceops say that
>> for a GET request to list account contents I should do (as with Swift):
>>
>> GET /{api version}/{account} HTTP/1.1
>>
>>
>> but, if I put the account RGW treats this as a bucket.
>>
>> So the following works fine:
>>
>> curl -i http://192.168.1.201:80/swift/v1 -X GET -H "X-Auth-Token: $token"
>>
>> But this does not:
>
> curl -i http://192.168.1.201:80/swift/v1/$account -X GET -H
> "X-Auth-Token: $token"
>
> Am I doing something wrong or is this an anomaly in the RGW API?
>

The docs are wrong there, the account is determined by the auth token.

Yehuda

Issue with RGW API

[Edward Hope-Morley]

Yehuda,

Thanks for your reply. Is this not a bit un-Swift like? I came across
this while testing the backup service for Openstack Cinder. Cinder
currently supports backup to Swift so I tested this against Rados
Gateway but it does not work because the it uses the standard
http://<server>/<version>/<account> format.

Also, there is an issue with PUTs where RGW returns a "411 Length
Required" in case the content-length is not specified. Is content-length
mandatory? Swift does not seem to complain. What are your thoughts on this?

(updated the subject since it was wrong)

Ed.

On 19/06/13 16:08, Yehuda Sadeh wrote:
> On Wed, Jun 19, 2013 at 3:03 AM, Edward Hope-Morley
> <opentastic@gmail.com> wrote:
>> Apologies, premature send ;)
>>
>> On 19/06/13 11:00, Edward Hope-Morley wrote:
>>> Hi guys, I'm having the following issue with the RGW swift API:
>>>
>>> The docs at http://ceph.com/docs/next/radosgw/swift/serviceops say that
>>> for a GET request to list account contents I should do (as with Swift):
>>>
>>> GET /{api version}/{account} HTTP/1.1
>>>
>>>
>>> but, if I put the account RGW treats this as a bucket.
>>>
>>> So the following works fine:
>>>
>>> curl -i http://192.168.1.201:80/swift/v1 -X GET -H "X-Auth-Token: $token"
>>>
>>> But this does not:
>> curl -i http://192.168.1.201:80/swift/v1/$account -X GET -H
>> "X-Auth-Token: $token"
>>
>> Am I doing something wrong or is this an anomaly in the RGW API?
>>
> The docs are wrong there, the account is determined by the auth token.
>
> Yehuda

Re: Issue with RGW API

[Yehuda Sadeh]

On Wed, Jun 19, 2013 at 8:21 AM, Edward Hope-Morley
<edward.hope-morley@canonical.com> wrote:
> Yehuda,
>
> Thanks for your reply. Is this not a bit un-Swift like? I came across
> this while testing the backup service for Openstack Cinder. Cinder
> currently supports backup to Swift so I tested this against Rados
> Gateway but it does not work because the it uses the standard
> http://<server>/<version>/<account> format.

The url should not be built directly, but rather use the returned
storage-url that it got when authenticated with the auth service.
Swift happens to build it in that format.

>
> Also, there is an issue with PUTs where RGW returns a "411 Length
> Required" in case the content-length is not specified. Is content-length
> mandatory? Swift does not seem to complain. What are your thoughts on this?
>
A PUT without content length needs to be chunked. If the missing
content-length is missing, we require 'Transfer-Encoding: chunked'.


> (updated the subject since it was wrong)
>
> Ed.
>
> On 19/06/13 16:08, Yehuda Sadeh wrote:
>> On Wed, Jun 19, 2013 at 3:03 AM, Edward Hope-Morley
>> <opentastic@gmail.com> wrote:
>>> Apologies, premature send ;)
>>>
>>> On 19/06/13 11:00, Edward Hope-Morley wrote:
>>>> Hi guys, I'm having the following issue with the RGW swift API:
>>>>
>>>> The docs at http://ceph.com/docs/next/radosgw/swift/serviceops say that
>>>> for a GET request to list account contents I should do (as with Swift):
>>>>
>>>> GET /{api version}/{account} HTTP/1.1
>>>>
>>>>
>>>> but, if I put the account RGW treats this as a bucket.
>>>>
>>>> So the following works fine:
>>>>
>>>> curl -i http://192.168.1.201:80/swift/v1 -X GET -H "X-Auth-Token: $token"
>>>>
>>>> But this does not:
>>> curl -i http://192.168.1.201:80/swift/v1/$account -X GET -H
>>> "X-Auth-Token: $token"
>>>
>>> Am I doing something wrong or is this an anomaly in the RGW API?
>>>
>> The docs are wrong there, the account is determined by the auth token.
>>
>> Yehuda
>