Hi Geoff, I'm very happy to know that companies like Cisco wants to use Reseller.
When we start the Hierarchical Multitenancy implementation we had some use cases in mind, there is: - Organize a divisional department of a company. - Reseller - Merge/Acquisition - Contracting parties The first use case are done with the implementation with HMT in Kilo-1, here we are requesting the FFE for Reseller and we want to implement the other use cases in a near future. These use cases are more focused in the Keystone side, but I believe that we can expand this feature for the other services, like we are trying to do implementing Nested Quotas in Nova https://github.com/openstack/nova-specs/blob/master/specs/kilo/approved/nested-quota-driver-api.rst (and in other services that have quotas control in Liberty). We are working to add the HMT support in Horizon. I like your use cases and we need a Design Session in the next summit, maybe a cross project session, to define the next steps for Reseller. Any questions I'm available. Cheers, Raildo On Fri, Mar 20, 2015 at 3:48 PM Geoff Arnold <ge...@geoffarnold.com> wrote: > Glad to see this FFE. The Cisco Cloud Services team is very interested in > the Reseller use case, and in a couple of possible extensions of the work. > http://specs.openstack.org/openstack/keystone-specs/ > specs/kilo/reseller.html covers the Keystone use cases, but there are > several other developments required in other OpenStack projects to come up > with a complete reseller “solution”. For my information, has anyone put > together an overarching blueprint which captures the top level Reseller use > cases and identifies all of the sub-projects and their dependencies? If so, > wonderful. If not, we might try to work on this in the new Product > Management WG. > > I mentioned “extensions” to http://specs.openstack.org/ > openstack/keystone-specs/specs/kilo/reseller.html . There are two that > we’re thinking about: > - the multi-provider reseller: adding the user story where Martha buys > OpenStack services from two or more > providers and presents them to her customers through a single Horizon > instance > - stacked reseller: Martha buys OpenStack services from a provider, Alex, > and also from a reseller, Chris, who > purchases OpenStack services from multiple providers > > In each case, the unit of resale is a “virtual region”: a provider region > subsetted using HMT/domains, with IdP supplied by the reseller, and > constrained by resource consumption policies (e.g. Nova AZ “foo” is not > available to customers of reseller “bar”). > > I strongly doubt that any of this is particularly original, but I haven’t > seen it written up anywhere. > > Cheers, > > Geoff Arnold > Cisco Cloud Services > geoar...@cisco.com > ge...@geoffarnold.com > @geoffarnold > > On Mar 19, 2015, at 11:22 AM, Raildo Mascena <rail...@gmail.com> wrote: > > In addition, > > In the last keystone meeting in March 17 in the IRC channel > <http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2015-03-17.log> > we > decided that Henry Nash (keystone core) will sponsor this feature as a FFE. > > Cheers, > > Raildo > > On Tue, Mar 17, 2015 at 5:36 PM Raildo Mascena <rail...@gmail.com> wrote: > >> Hi Folks, >> >> We’ve discussed a lot in the last Summit about the Reseller use case. >> OpenStack needs to grow support for hierarchical ownership of objects.This >> enables the management of subsets of users and projects in a way that is >> much more comfortable for private clouds, besides giving to public cloud >> providers the option of reselling a piece of their cloud. >> >> More detailed information can be found in the spec for this change at: >> https://review.openstack.org/#/c/139824 >> >> The current code change for this is split into 8 patches (to make it >> easier to review). We currently have 7 patches in code review and we are >> finishing the last one. >> >> Here is the workflow of our patches: >> >> 1- Adding a field to enable the possibility to have a project with the >> domain "feature": https://review.openstack.org/#/c/157427/ >> >> 2- Change some constraints and create some options to list projects (for >> is_domain flag, for parent_id): >> https://review.openstack.org/#/c/159944/ >> https://review.openstack.org/#/c/158398/ >> https://review.openstack.org/#/c/161378/ >> https://review.openstack.org/#/c/158372/ >> >> 3- Reflect domain operations to project table, mapping domains to >> projects that have the is_domain attribute set to True. In addition, it >> changes the read operations to use only the project table. Then, we will >> drop the Domain Table. >> https://review.openstack.org/#/c/143763/ >> https://review.openstack.org/#/c/161854/ (Only patch with work in >> progress) >> >> 4- Finally, the inherited role will not be applied to a subdomain and its >> sub hierarchy. https://review.openstack.org/#/c/164180/ >> >> Since we have the implementation almost completed, waiting for code >> review, I am requesting an FFE to enable the implementation of this last >> patch and work to have this implementation merged in Kilo. >> >> >> Raildo >> > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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
