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 <adri...@catalyst.net.nz> 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 <henryna...@mac.com> 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. > > Henry > > On 16 Mar 2017, at 21:10, Lance Bragstad <lbrags...@gmail.com > <mailto:lbrags...@gmail.com>> 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 > > <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 > <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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
__________________________________________________________________________ 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
