<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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:<div class=""><br class=""></div><div class="">1) Project hierarchy support</div><div class="">2) Domains are actually projects under-the-hood, with a special attribute (is_project == true).</div><div class="">3) Hence domains are already part of the hierarchy - they just are only allowed to be the root of a tree.</div><div class="">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)</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">a) How do we continually sync the catalogs? Presumably you would want all the endpoints (except keystone) to be the same in each catalog? </div><div class="">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?</div><div class="">c) How to stop “admin” from one keystone from being treated as general “admin” on, say, a nova endpoint?</div><div class="">d) On-boarding a reseller would be a more manual process (i.e. you need to set up federation mappings etc.)</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Henry</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On 17 Mar 2017, at 10:38, Adrian Turjak <<a href="mailto:adriant@catalyst.net.nz" class="">adriant@catalyst.net.nz</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class="">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.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">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.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">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.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">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!</div><div dir="auto" class=""><br class=""></div><div dir="auto" class=""><br class=""><div class="gmail_extra" dir="auto"><br class=""><div class="gmail_quote">On 17 Mar. 2017 10:27 pm, Henry Nash <<a href="mailto:henrynash9@mac.com" class="">henrynash9@mac.com</a>> wrote:<br type="attribution" class=""><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">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:<div class=""><br class=""></div><div class="">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.</div><div class="">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.</div><div class="">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.</div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Henry</div><div class=""><br class=""><div class=""><blockquote class=""><div class="">On 16 Mar 2017, at 21:10, Lance Bragstad <<a href="mailto:lbragstad@gmail.com" class="">lbragstad@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Hey folks,<div class=""><br class=""></div><div class="">The reseller use case [0] has been popping up frequently in various discussions [1], including unified limits.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">Are you interested in reseller and willing to provide use-cases?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">[0] <a href="http://specs.openstack.org/openstack/keystone-specs/specs/keystone/mitaka/reseller.html#problem-description" class="">http://specs.openstack.org/openstack/keystone-specs/specs/keystone/mitaka/reseller.html#problem-description</a></div></div>
__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></div>__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></blockquote></div><br class=""></body></html>