<div dir="ltr">Hi Geoff,<br><br>I'm very happy to know that companies like Cisco wants to use Reseller. <br><br>When we start the Hierarchical Multitenancy implementation we had some use cases in mind, there is:<br><br>- Organize a divisional department of a company.<br>- Reseller<br>- Merge/Acquisition <br>- Contracting parties <br><br>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.<br><br>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 <a href="https://github.com/openstack/nova-specs/blob/master/specs/kilo/approved/nested-quota-driver-api.rst">https://github.com/openstack/nova-specs/blob/master/specs/kilo/approved/nested-quota-driver-api.rst</a> (and in other services that have quotas control in Liberty). We are working to add the HMT support in Horizon.<br><br>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.<br><br>Any questions I'm available.<br><br>Cheers, <br><br>Raildo<div><br><div><div class="gmail_quote">On Fri, Mar 20, 2015 at 3:48 PM Geoff Arnold <<a href="mailto:geoff@geoffarnold.com" target="_blank">geoff@geoffarnold.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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. <a href="http://specs.openstack.org/openstack/keystone-specs/specs/kilo/reseller.html" target="_blank">http://specs.openstack.<u></u>org/openstack/keystone-specs/<u></u>specs/kilo/reseller.html</a> <u></u>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.<div><br></div><div>I mentioned “extensions” to <a href="http://specs.openstack.org/openstack/keystone-specs/specs/kilo/reseller.html" target="_blank">http://specs.openstack.org/<u></u>openstack/keystone-specs/<u></u>specs/kilo/reseller.html</a> . There are two that we’re thinking about:</div><div>- the multi-provider reseller: adding the user story where Martha buys OpenStack services from two or more </div><div>  providers and presents them to her customers through a single Horizon instance</div><div>- stacked reseller: Martha buys OpenStack services from a provider, Alex, and also from a reseller, Chris, who </div><div>  purchases OpenStack services from multiple providers </div><div><br></div><div>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”).</div><div><br></div><div>I strongly doubt that any of this is particularly original, but I haven’t seen it written up anywhere.</div><div><br></div><div>Cheers,</div><div><br></div><div>Geoff Arnold</div><div>Cisco Cloud Services</div><div><a href="mailto:geoarnol@cisco.com" target="_blank">geoarnol@cisco.com</a></div><div><a href="mailto:geoff@geoffarnold.com" target="_blank">geoff@geoffarnold.com</a></div><div>@geoffarnold</div><div><br><div><div><blockquote type="cite"></blockquote></div></div></div></div><div style="word-wrap:break-word"><div><div><div><blockquote type="cite"><div>On Mar 19, 2015, at 11:22 AM, Raildo Mascena <<a href="mailto:raildom@gmail.com" target="_blank">raildom@gmail.com</a>> wrote:</div><br></blockquote></div></div></div></div><div style="word-wrap:break-word"><div><div><div><blockquote type="cite"><div><div dir="ltr">In addition, <br><br>In the last keystone meeting in March 17 in the <a href="http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2015-03-17.log" target="_blank">IRC channel</a> we decided that Henry Nash (keystone core) will sponsor this feature as a FFE.<div><br></div><div>Cheers,</div><div><br></div><div>Raildo</div></div><br><div class="gmail_quote">On Tue, Mar 17, 2015 at 5:36 PM Raildo Mascena <<a href="mailto:raildom@gmail.com" target="_blank">raildom@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Folks,<br><br>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.<div><br>More detailed information can be found in the spec for this change at: <a href="https://review.openstack.org/#/c/139824" target="_blank">https://review.openstack.org/#<u></u>/c/139824</a><br><br>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.<br><br>Here is the workflow of our patches:<br><br>1- Adding a field to enable the possibility to have a project with the domain "feature": <a href="https://review.openstack.org/#/c/157427/" target="_blank">https://review.openstack.org/#<u></u>/c/157427/</a><br><br>2- Change some constraints and create some options to list projects (for is_domain flag, for parent_id):<br><a href="https://review.openstack.org/#/c/159944/" target="_blank">https://review.openstack.org/#<u></u>/c/159944/</a><br><a href="https://review.openstack.org/#/c/158398/" target="_blank">https://review.openstack.org/#<u></u>/c/158398/</a><br><a href="https://review.openstack.org/#/c/161378/" target="_blank">https://review.openstack.org/#<u></u>/c/161378/</a><br><a href="https://review.openstack.org/#/c/158372/" target="_blank">https://review.openstack.org/#<u></u>/c/158372/</a><br><br>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.<br><a href="https://review.openstack.org/#/c/143763/" target="_blank">https://review.openstack.org/#<u></u>/c/143763/</a><br><a href="https://review.openstack.org/#/c/161854/" target="_blank">https://review.openstack.org/#<u></u>/c/161854/</a>  (Only patch with work in progress)<br><br>4- Finally, the inherited role will not be applied to a subdomain and its sub hierarchy. <a href="https://review.openstack.org/#/c/164180/" target="_blank">https://review.openstack.org/#<u></u>/c/164180/</a><br><br>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.</div></div><div dir="ltr"><div><br><br>Raildo<br></div></div></blockquote></div></div></blockquote></div></div></div></div><div style="word-wrap:break-word"><div><div><div><blockquote type="cite"><div>
______________________________<u></u>______________________________<u></u>______________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org</a>?subject:<u></u>unsubscribe<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br></div></blockquote></div><br></div></div></div>______________________________<u></u><u></u>______________________________<u></u><u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>op<u></u>enstack.org?subject:<u></u>unsubscrib<u></u>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi<u></u>-bin/mailman/listinfo/<u></u>openstac<u></u>k-dev</a><br>
</blockquote></div></div></div></div>