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