<div dir='auto'><div>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"><br></div><div dir="auto">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"><br></div><div dir="auto">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"><br></div><div dir="auto">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"><br></div><div dir="auto"><br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On 17 Mar. 2017 10:27 pm, Henry Nash <henrynash9@mac.com> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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><br></div><div>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>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>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>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><br></div><div>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><br></div><div>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><br></div><div>Henry</div><div><br><div><blockquote><div>On 16 Mar 2017, at 21:10, Lance Bragstad <<a href="mailto:lbragstad@gmail.com">lbragstad@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Hey folks,<div><br></div><div>The reseller use case [0] has been popping up frequently in various discussions [1], including unified limits.</div><div><br></div><div>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><br></div><div>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><br></div><div>Are you interested in reseller and willing to provide use-cases?</div><div><br></div><div><br></div><div><br></div><div>[0] <a href="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</a></div></div>
__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div></blockquote></div><br></div></div></blockquote></div><br></div></div></div>