Open Stack

On 16 Mar 2017, at 14:10, Lance Bragstad wrote:

> Hey folks,
>
> The reseller use case [0] has been popping up frequently in various
> discussions [1], including unified limits.
>
> For those who are unfamiliar with the reseller concept, it came out of
> early discussions regarding hierarchical multi-tenancy (HMT). It
> essentially allows a certain level of opaqueness within project trees. This
> opaqueness would make it easier for providers to "resell" infrastructure,
> without having customers/providers see all the way up and down the project
> tree, hence it was termed reseller. Keystone originally had some ideas of
> how to implement this after the HMT implementation laid the ground work,
> but it was never finished.
>
> With it popping back up in conversations, I'm looking for folks who are
> willing to represent the idea. Participating in this thread doesn't mean
> you're on the hook for implementing it or anything like that.
>
> Are you interested in reseller and willing to provide use-cases?
>
>
>
> [0]
> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/mitaka/reseller.html#problem-description



This is interesting to me. It sounds very similar to the reseller concept that Swift has. In Swift, the reseller is used to group accounts. Remember that an account in Swift is like a bank account. It's where you put stuff, and is mapped to one or more users via an auth system. So a Swift account is scoped to a particular reseller, and an auth system is responsible for one or more resellers.

You can see this in practice with the "reseller prefix" that's used in Swift's URLs. The default is "AUTH_", so my account might be "AUTH_john". But it's totally possible that there could be another auth system assigned to a different reseller prefix. If that other reseller prefix is "BAUTH_", then there could exist a totally independent "BAUTH_john" account. The only thing that ties some user creds (or token) to a particular account in Swift is the auth system.

So this reseller concept in Swift allows deployers to have more than one auth system installed in the same cluster at the same time. And, in fact, this is exactly why it was first used. If you get an account with Rackspace Cloud Files, you'll see the reseller prefix is "MossoCloudFS_", but it turns out that when Swift was created JungleDisk was an internal Rackspace product and also stored a bunch of data in the same system. JungleDisk managed it's own users and auth system, so they had a different reseller prefix that was tied to a different auth system.

From the Keystone spec, it seems that the reseller idea is a way to group domains, very much like the reseller concept in Swift. I'd suggest that instead of building ever-increasing hierarchies of groups of users, supporting more than one auth system at a time is a proven way to scale out this solution. So instead of adding the complexity to Keystone of ever-deepening groupings, support having more than one Keystone instance (or even Keystone + another auth system) in a project's pipeline. This allows grouping users into distinct partitions, and it scales by adding more keystones instead of bigger keystones.


--John




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170316/51d085dd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170316/51d085dd/attachment.pgp>