Open Stack

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 <geoff at 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
> geoarnol at cisco.com
> geoff at geoffarnold.com
> @geoffarnold
>
> On Mar 19, 2015, at 11:22 AM, Raildo Mascena <raildom at 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 <raildom at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150320/c6a33b67/attachment.html>