Re: [rgw] Multi-tenancy support in radosgw
Hello Pete, On Tue, Sep 15, 2015 at 7:10 AM, Pete Zaitcev wrote: > On Sat, 12 Sep 2015 00:24:27 +0200 > Radoslaw Zarzynski wrote: > >> Each already existing user would obtain empty bucket namespace >> by default. It will be possible to create user with his own, unique >> namespace. [...] > >> 2. We will always need ID of namespace in order to access proper >> bucket entry points. [...] > >> I would like to ask for reviews of the idea and feedback. > > I still don't understand how this is different from tenants in wip-5073. > Each tenant defines what amounts to a namespace for buckets. Could you > clear this up? I heard you discussing it a little bit during the RGW > team stand-up call, but I can't wrap my head around it. Tenant is much more wider concept. In wip-5073 not only bucket entry points got a prefix, but account as well. This huge, global namespace was called tenant. In effect, listing of RADOS pool storing serialized RGWUserInfo and buckets register for a given account was looking like the following example: $ rados -p .users.uid ls 68a23e70b5854263ab64f2ddc16c2a38:68a23e70b5854263ab64f2ddc16c2a38.buckets 68a23e70b5854263ab64f2ddc16c2a38:68a23e70b5854263ab64f2ddc16c2a38 where '68a23e70b5854263ab64f2ddc16c2a38' in an account ID. It's also worth to mention that accounts and users in radosgw are a bit blurred - RGWUserInfo describes both entities. I'm visualizing that as a composition - account always has an owner who is so tightly bound to it that they share even a common identifier - UID. > Secondly, have you given a thought to exact API here, or is it all > hand-waved for now? As you may know, initially I hoped we'd get by > without adding any special syntax for tenants. Just off-load it onto > the authentication system, I thought. That didn't work and now we > have the tenant$user syntax allowed all over. > > What I mean by that, a client has to do "swift -U tenant\$user:subuser -K > pass" > in 5073, and that looks a bit fraught. I presume you avoided that. Yes, avoiding that was a requirement. > Specifically though, imagine I'm doing "radosgw-admin user info", > what do I get under your plan? You would get everything as usual with one, small exception - boolean indicating whether the account has its own namespace for bucket entry points or not. We really need that due to the compatibility with already existing clusters. Of course, S3 also will be able to use non-empty BNS. However, I plan to not enforce that. > P.S. What repo/branch do you use for this? I know you quoted it before, > but just so we're at the same place. Initial BNS implementation has been sent as a pull request [1]. I'm also working on separating account's owner from user involved in RGWOp authorization process [2] (*::verify_permission methods). Best regards, Radek [1] https://github.com/ceph/ceph/pull/5872 [2] https://github.com/rzarzynski/ceph/tree/wip-5073-bns-authsep -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rgw] Multi-tenancy support in radosgw
On Sat, 12 Sep 2015 00:24:27 +0200 Radoslaw Zarzynski wrote: > Each already existing user would obtain empty bucket namespace > by default. It will be possible to create user with his own, unique > namespace. [...] > 2. We will always need ID of namespace in order to access proper > bucket entry points. [...] > I would like to ask for reviews of the idea and feedback. I still don't understand how this is different from tenants in wip-5073. Each tenant defines what amounts to a namespace for buckets. Could you clear this up? I heard you discussing it a little bit during the RGW team stand-up call, but I can't wrap my head around it. Secondly, have you given a thought to exact API here, or is it all hand-waved for now? As you may know, initially I hoped we'd get by without adding any special syntax for tenants. Just off-load it onto the authentication system, I thought. That didn't work and now we have the tenant$user syntax allowed all over. What I mean by that, a client has to do "swift -U tenant\$user:subuser -K pass" in 5073, and that looks a bit fraught. I presume you avoided that. Specifically though, imagine I'm doing "radosgw-admin user info", what do I get under your plan? -- Pete P.S. What repo/branch do you use for this? I know you quoted it before, but just so we're at the same place. -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rgw] Multi-tenancy support in radosgw
On Fri, Sep 11, 2015 at 3:24 PM, Radoslaw Zarzynski wrote: > Hello, > > It's a well-known trait of radosgw that an user cannot create new > bucket with a given name if the name is already occupied by other > user's bucket (request to do that will be rejected with 409 Conflict). > This behaviour is entirely expected in S3. However, when it comes > to Swift API, it turns into huge limitation. > > In my opinion the root cause lies in how radosgw actually handles > bucket entry points. They might be seen as symlinks which must > be resolved in order to map bucket names exposed to users into > concrete bucket instances: > > bucket name -> unique bucket instance ID > > It's completely clear we need to preserve backward compatibility. > Thus we cannot simply append ID of user who owns a given > bucket to argument list of mapping function. We would have to > introduce an indirection layer - bucket namespaces: > > bucket namespace, bucket name -> unique bucket instance ID > > Each already existing user would obtain empty bucket namespace > by default. It will be possible to create user with his own, unique > namespace. > > Generally this looks to me as stupidly simple solution. Of course, > it has limitations. At the moment I see following things: > > 1. We may need to develop a new mechanism for moving buckets > between namespaces in radosgw-admin. The already existing > one for linking/unlinking might be not enough. This is a nice to have, not sure we actually need that. > > 2. We will always need ID of namespace in order to access proper > bucket entry points. This is not a problem for requests authorized > through Keystone/TempAuth because user ID is known and thus > BNS may be easily calculated. > Anonymous access/TempURL for bucket with non-empty namespace > is a different story. In this case BNS must be provided explicitly. > Swift resolves the problem by having account name as a part of URL. > We could go the same way. This would be extended by decoupling > rgw_user used for storage access purposes from the one for > authorizing a given operation (RGWOp::verify_permission() method). > > > I would like to ask for reviews of the idea and feedback. > I think that it's orthogonal to the whole multi-tenancy issue. It might solve a specific requirement, but doesn't address the entire scope of multitenancy. But it's probably a good idea to have it anyway, as it adds a needed layer of abstraction. I also think that we shouldn't treat this as a swift specific issue. We should make it configurable and work for both S3 and swift. Yehuda -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[rgw] Multi-tenancy support in radosgw
Hello, It's a well-known trait of radosgw that an user cannot create new bucket with a given name if the name is already occupied by other user's bucket (request to do that will be rejected with 409 Conflict). This behaviour is entirely expected in S3. However, when it comes to Swift API, it turns into huge limitation. In my opinion the root cause lies in how radosgw actually handles bucket entry points. They might be seen as symlinks which must be resolved in order to map bucket names exposed to users into concrete bucket instances: bucket name -> unique bucket instance ID It's completely clear we need to preserve backward compatibility. Thus we cannot simply append ID of user who owns a given bucket to argument list of mapping function. We would have to introduce an indirection layer - bucket namespaces: bucket namespace, bucket name -> unique bucket instance ID Each already existing user would obtain empty bucket namespace by default. It will be possible to create user with his own, unique namespace. Generally this looks to me as stupidly simple solution. Of course, it has limitations. At the moment I see following things: 1. We may need to develop a new mechanism for moving buckets between namespaces in radosgw-admin. The already existing one for linking/unlinking might be not enough. 2. We will always need ID of namespace in order to access proper bucket entry points. This is not a problem for requests authorized through Keystone/TempAuth because user ID is known and thus BNS may be easily calculated. Anonymous access/TempURL for bucket with non-empty namespace is a different story. In this case BNS must be provided explicitly. Swift resolves the problem by having account name as a part of URL. We could go the same way. This would be extended by decoupling rgw_user used for storage access purposes from the one for authorizing a given operation (RGWOp::verify_permission() method). I would like to ask for reviews of the idea and feedback. Best regards, Radoslaw Zarzynski -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
