Re: [openstack-dev] [keystone][all] Reseller - do we need it?

[Henry Nash]

Yes, that was indeed the model originally proposed (some referred to it as 
“nested domains”). Back then we didn’t have project hierarchy support in 
keystone (actually the two requirements emerged together and intertwined - and 
for a while there was a joint spec). Today, there are some interesting 
characteristics in keystone:

1) Project hierarchy support
2) Domains are actually projects under-the-hood, with a special attribute 
(is_project == true).
3) Hence domains are already part of the hierarchy - they just are only allowed 
to be the root of a tree.
4) In fact, if we really want to get technical, in keystone the project 
representing a domain does actually have a parent (the hidden “root of all 
domains” which we don’t expose at the API level)

So from the above, once can see that allowing more than one layer of domains at 
the top of the tree would be (implantation wise) relative easy.  Although this 
has traditionally been my preferred solution, just ‘cause it is alluring and 
seems easy, doesn’t mean it is necessarily the right solution.

The most common alternative proposed is to use some kind of federation. The 
most likely scenario would be that the relationship between the cloud owner and 
a reseller would be a federated one, while the relationship between a reseller 
and their customers would be a traditional one of each customer having a 
domain. Some of the challenges to this approach would be:

a) How do we continually sync the catalogs? Presumably you would want all the 
endpoints (except keystone) to be the same in each catalog? 
b) What are the problems with having the same endpoint registered in multiple 
catalogs? How would keystone middleware on a common, say, nova endpoint know 
which keystone to validate with?
c) How to stop “admin” from one keystone from being treated as general “admin” 
on, say, a nova endpoint?
d) On-boarding a reseller would be a more manual process (i.e. you need to set 
up federation mappings etc.)

In some respects, you could argue that if I were a reseller, I would like this 
federated model better. I know, for sure, that nobody outside of my VCO can get 
access (i.e. since I have my own keystone, and token obtained from a different 
reseller’s keystone has no chance of getting in). However, I don’t believe we 
have every explored how to solve the various issues above.

Henry

> On 17 Mar 2017, at 10:38, Adrian Turjak  wrote:
> 
> This actually sounds a lot like a domain per reseller, with a sub-domain per 
> reseller customer. With the reseller themselves probably also running a 
> sub-domain or two for themselves. Mayb even running their own external 
> federated user system for that specific reseller domain.
> 
> That or something like it could be doable. The reseller would be aware of the 
> resources (likely to bill) and projects (since you would still likely bill 
> project or at least tag invoice items per project), so the hidden project 
> concept doesn't really fit.
> 
> One thing that I do think is useful, and we've done for our cloud, is letting 
> users see who exactly has access to their projects. For our Horizon we have a 
> custom identity/access control panel that shows clearly who has access on 
> your project and once I add on proper inheritance support will also list 
> users who has inherited access for the project you are currently scoped to. 
> This means a customer knows and can see when an admin has added themselves to 
> their project to help debug something. Plus it even helps them in general 
> manage their own user access better.
> 
> I know we've been looking at the reseller model ourselves but haven't really 
> gotten anywhere with it, partly because the margins didn't seem worth it, but 
> also because the complexity of shoe-horning it around our existing openstack 
> deployment. Domain per reseller (reseller as domain admin) and sub-domain per 
> reseller customer (as sub-domain admin) I'm interested in!
> 
> 
> 
> On 17 Mar. 2017 10:27 pm, Henry Nash  wrote:
> OK, so I worked on the original spec for this in Keystone, based around real 
> world requirements we (IBM) saw.  For the record, here’s the particular goal 
> we wanted to achieve:
> 
> 1) A cloud owner (i.e. the enterprise owns and maintains the core of the 
> cloud), wants to attract more traffic by using third-party resellers or 
> partners.
> 2) Those resellers will sell “cloud” to their own customers and be 
> responsible for finding & managing such customers. These resellers want to be 
> able to onboard such customers and “hand them the admin keys” to they 
> respective (conceptual) pieces of the cloud. I.e. Reseller X signs up 
> Customer Y. Customer Y gets “keystone admin” for their bit of the (shared) 
> cloud, and then can create and manage their own users without either the 
> Reseller or the Overall cloud owner being involved. In keystone terms, each 
> actual customer gets the equivalent of a domain, so 

Re: [openstack-dev] [keystone][all] Reseller - do we need it?

[Adrian Turjak]

This actually sounds a lot like a domain per reseller, with a sub-domain per reseller customer. With the reseller themselves probably also running a sub-domain or two for themselves. Mayb even running their own external federated user system for that specific reseller domain.That or something like it could be doable. The reseller would be aware of the resources (likely to bill) and projects (since you would still likely bill project or at least tag invoice items per project), so the hidden project concept doesn't really fit.One thing that I do think is useful, and we've done for our cloud, is letting users see who exactly has access to their projects. For our Horizon we have a custom identity/access control panel that shows clearly who has access on your project and once I add on proper inheritance support will also list users who has inherited access for the project you are currently scoped to. This means a customer knows and can see when an admin has added themselves to their project to help debug something. Plus it even helps them in general manage their own user access better.I know we've been looking at the reseller model ourselves but haven't really gotten anywhere with it, partly because the margins didn't seem worth it, but also because the complexity of shoe-horning it around our existing openstack deployment. Domain per reseller (reseller as domain admin) and sub-domain per reseller customer (as sub-domain admin) I'm interested in!On 17 Mar. 2017 10:27 pm, Henry Nash  wrote:OK, so I worked on the original spec for this in Keystone, based around real world requirements we (IBM) saw.  For the record, here’s the particular goal we wanted to achieve:1) A cloud owner (i.e. the enterprise owns and maintains the core of the cloud), wants to attract more traffic by using third-party resellers or partners.2) Those resellers will sell “cloud” to their own customers and be responsible for finding & managing such customers. These resellers want to be able to onboard such customers and “hand them the admin keys” to they respective (conceptual) pieces of the cloud. I.e. Reseller X signs up Customer Y. Customer Y gets “keystone admin” for their bit of the (shared) cloud, and then can create and manage their own users without either the Reseller or the Overall cloud owner being involved. In keystone terms, each actual customer gets the equivalent of a domain, so that their users are separate from another other customers’ users across all resellers.3) Resellers will want to be able to have a view of all their customers (but ONLY their customers, not those of another reseller), e.g. assign quotas to each one…and make sure the overall quota for all their customers has not exceeded their own quota agreed with the overall cloud owner. Resellers may sell addiction services to their customers, e.g. act as support for problems, do backups whatever - things that might need them to have controlled access particular customers' pieces of the cloud - i.e. they might need roles (or at least some kind of access rights) on their customer’s cloud.4) In all of the above, by default, all hardware is shared and their are no dedicated endpoints (e.g. nova, neutron, keystone etc. are all shared), although such dedication should not be prevented should a customer want it.The above is somewhat analogous to how mobile virtual networks operators (MVNO) work - e.g. in the UK if I sign up for Sky Mobile, it is actually using the O2 network. As a Sky customer, I just know Sky - I’m not aware that Sky don’t own the network. Sky do own there on BSS/CRM systems - but they are not core network components. The idea was to provide someone similar for an OpenStack cloud provider, where they could support VCOs (Virtual Cloud Operators) on the their cloud.I agree there are multiple ways to provide such a capability - and it is often difficult to decide what should be within the “Openstack” scope, and what should be provided outside of it.HenryOn 16 Mar 2017, at 21: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] 

Re: [openstack-dev] [keystone][all] Reseller - do we need it?

[Henry Nash]

OK, so I worked on the original spec for this in Keystone, based around real 
world requirements we (IBM) saw.  For the record, here’s the particular goal we 
wanted to achieve:

1) A cloud owner (i.e. the enterprise owns and maintains the core of the 
cloud), wants to attract more traffic by using third-party resellers or 
partners.
2) Those resellers will sell “cloud” to their own customers and be responsible 
for finding & managing such customers. These resellers want to be able to 
onboard such customers and “hand them the admin keys” to they respective 
(conceptual) pieces of the cloud. I.e. Reseller X signs up Customer Y. Customer 
Y gets “keystone admin” for their bit of the (shared) cloud, and then can 
create and manage their own users without either the Reseller or the Overall 
cloud owner being involved. In keystone terms, each actual customer gets the 
equivalent of a domain, so that their users are separate from another other 
customers’ users across all resellers.
3) Resellers will want to be able to have a view of all their customers (but 
ONLY their customers, not those of another reseller), e.g. assign quotas to 
each one…and make sure the overall quota for all their customers has not 
exceeded their own quota agreed with the overall cloud owner. Resellers may 
sell addiction services to their customers, e.g. act as support for problems, 
do backups whatever - things that might need them to have controlled access 
particular customers' pieces of the cloud - i.e. they might need roles (or at 
least some kind of access rights) on their customer’s cloud.
4) In all of the above, by default, all hardware is shared and their are no 
dedicated endpoints (e.g. nova, neutron, keystone etc. are all shared), 
although such dedication should not be prevented should a customer want it.

The above is somewhat analogous to how mobile virtual networks operators (MVNO) 
work - e.g. in the UK if I sign up for Sky Mobile, it is actually using the O2 
network. As a Sky customer, I just know Sky - I’m not aware that Sky don’t own 
the network. Sky do own there on BSS/CRM systems - but they are not core 
network components. The idea was to provide someone similar for an OpenStack 
cloud provider, where they could support VCOs (Virtual Cloud Operators) on the 
their cloud.

I agree there are multiple ways to provide such a capability - and it is often 
difficult to decide what should be within the “Openstack” scope, and what 
should be provided outside of it.

Henry

> On 16 Mar 2017, at 21: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
>  
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][all] Reseller - do we need it?

[Tim Bell]

Lance,

I had understood that the resellers was about having users/groups at the 
different points in the tree.

I think the basic resource management is being looked at as part of the nested 
quotas functionality. For CERN, we’d look to delegate the quota and roles 
management but not support sub-tree user/groups.

Tim

From: Lance Bragstad <lbrags...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Friday, 17 March 2017 at 00:23
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [keystone][all] Reseller - do we need it?


On Thu, Mar 16, 2017 at 5:54 PM, Fox, Kevin M 
<kevin@pnnl.gov<mailto:kevin@pnnl.gov>> wrote:
At our site, we have some larger projects that would be really nice if we could 
just give a main project all the resources they need, and let them suballocate 
it as their own internal subprojects needs change. Right now, we have to deal 
with all the subprojects directly. The reseller concept may fit this use case?

Sounds like this might also be solved by better RBAC that allows real project 
administrators to control their own subtrees. Is there a use case to limit 
visibility either up or down the tree? If not, would it be a nice-to-have?


Thanks,
Kevin

From: Lance Bragstad [lbrags...@gmail.com<mailto:lbrags...@gmail.com>]
Sent: Thursday, March 16, 2017 2:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [keystone][all] Reseller - do we need it?
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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][all] Reseller - do we need it?

[Lance Bragstad]

On Thu, Mar 16, 2017 at 4:31 PM, John Dickinson  wrote:

>
>
> 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.
>

This is super interesting, I've never thought about it this way before. In
your example was there information that was shared that both auth systems
needed? If so, do you remember how that was done?

So, if I think about this conceptually...

Is it safe to assume that both identity systems have to share a subset of
information (i.e. regions, services, endpoints, roles, etc.) or they have
to duplicate data? Phrasing it as a question actually reminds me of a time
when folks came to keystone asking if they could isolate the storage of
users and groups from the rest of the deployment (i.e. the identity table
of keystone database would be region specific and the rest of the database
would be shared globally). Instead of performing that isolation, we've seen
that as more of need to improve federated use-cases (because why couldn't
that be solved with federation).

So, building on your separate identity systems idea. What if we had a way
to redirect authentication requests to an identity provider based on the
domain being operated in? The other identity system could be keystone, it
could be something else, whatever serves up SAML assertions. If you wanted
to provide a reseller environment for a customer you could do so by setting
up a keystone-to-keystone federated environment, making the reseller's
keystone the identity provider for that domain. I guess the real big hurdle
now is what to do with projects, because the whole idea of reseller is to
have the ability to create and manage my own subtrees. In today's world,
projects and domains are left up to the service provider to manage.

Feel free to reel me back in if I've gone off the deep end!


>

Re: [openstack-dev] [keystone][all] Reseller - do we need it?

[Fox, Kevin M]

Yeah, that would probably handle the use case too.

Thanks,
Kevin

From: Lance Bragstad [lbrags...@gmail.com]
Sent: Thursday, March 16, 2017 4:23 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone][all] Reseller - do we need it?


On Thu, Mar 16, 2017 at 5:54 PM, Fox, Kevin M 
<kevin@pnnl.gov<mailto:kevin@pnnl.gov>> wrote:
At our site, we have some larger projects that would be really nice if we could 
just give a main project all the resources they need, and let them suballocate 
it as their own internal subprojects needs change. Right now, we have to deal 
with all the subprojects directly. The reseller concept may fit this use case?

Sounds like this might also be solved by better RBAC that allows real project 
administrators to control their own subtrees. Is there a use case to limit 
visibility either up or down the tree? If not, would it be a nice-to-have?


Thanks,
Kevin


From: Lance Bragstad [lbrags...@gmail.com<mailto:lbrags...@gmail.com>]
Sent: Thursday, March 16, 2017 2:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [keystone][all] Reseller - do we need it?

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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][all] Reseller - do we need it?

[Lance Bragstad]

On Thu, Mar 16, 2017 at 5:54 PM, Fox, Kevin M  wrote:

> At our site, we have some larger projects that would be really nice if we
> could just give a main project all the resources they need, and let them
> suballocate it as their own internal subprojects needs change. Right now,
> we have to deal with all the subprojects directly. The reseller concept may
> fit this use case?
>

Sounds like this might also be solved by better RBAC that allows real
project administrators to control their own subtrees. Is there a use case
to limit visibility either up or down the tree? If not, would it be a
nice-to-have?


>
> Thanks,
> Kevin
>
> --
> *From:* Lance Bragstad [lbrags...@gmail.com]
> *Sent:* Thursday, March 16, 2017 2:10 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [keystone][all] Reseller - do we need it?
>
> 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
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][all] Reseller - do we need it?

[Fox, Kevin M]

At our site, we have some larger projects that would be really nice if we could 
just give a main project all the resources they need, and let them suballocate 
it as their own internal subprojects needs change. Right now, we have to deal 
with all the subprojects directly. The reseller concept may fit this use case?

Thanks,
Kevin


From: Lance Bragstad [lbrags...@gmail.com]
Sent: Thursday, March 16, 2017 2:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [keystone][all] Reseller - do we need it?

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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][all] Reseller - do we need it?

[John Dickinson]

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






signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev