[openstack-dev] [keystone][nova] Re: Hierarchicical Multitenancy Discussion

Adam Young ayoung at redhat.com
Fri Feb 7 01:57:16 UTC 2014


On 02/06/2014 05:18 AM, Florent Flament wrote:
> Vish:
>
> +1 for hierchical IDs (e.g:
> b04f9ea01a9944ac903526885a2666de.c45674c5c2c6463dad3c0cb9d7b8a6d8)

Please keep names and identifiers separate.  Identifiers should *NOT* be 
hierarchical.  Names can be.

Think of the operating system distinction between dentries (names) and 
Inode identifiers (IDs)   only dentries are hierarchical.


If you want to move something from one container to another, and 
maintain identity, use the same id,  just "mount" it somewhere else.

> (names used for clarity of explanations).
>
> Chris:
>
> +1 for hierarchical /project flavors, images, and so on	..
>
> Vinod, Vish:
>
> Starting new Thread "[openstack-dev][keystone] Centralized policy rules
> and quotas" for thoughts about centralized RBAC rules and Quotas.
>
>
> Florent Flament
>
>
> ----- Original Message -----
> From: "Chris Behrens" <cbehrens at codestud.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Wednesday, February 5, 2014 8:43:08 PM
> Subject: Re: [openstack-dev] [keystone][nova] Re: Hierarchicical	Multitenancy Discussion
>
>
> On Feb 5, 2014, at 3:38 AM, Vishvananda Ishaya <vishvananda at gmail.com> wrote:
>
>> On Feb 5, 2014, at 12:27 AM, Chris Behrens <cbehrens at codestud.com> wrote:
>>
>>> 1) domain ‘a’ cannot see instances (or resources in general) in domain ‘b’. It doesn’t matter if domain ‘a’ and domain ‘b’ share the same tenant ID. If you act with the API on behalf of domain ‘a’, you cannot see your instances in domain ‘b’.
>>> 2) Flavors per domain. domain ‘a’ can have different flavors than domain ‘b’.
>> I hadn’t thought of this one, but we do have per-project flavors so I think this could work in a project hierarchy world. We might have to rethink the idea of global flavors and just stick them in the top-level project. That way the flavors could be removed. The flavor list would have to be composed by matching all parent projects. It might make sense to have an option for flavors to be “hidden" in sub projects somehow as well. In other words if orgb wants to delete a flavor from the global list they could do it by hiding the flavor.
>>
>> Definitely some things to be thought about here.
> Yeah, it's completely do-able in some way. The per-project flavors is a good start.
>
>>> 3) Images per domain. domain ‘a’ could see different images than domain ‘b’.
>> Yes this would require similar hierarchical support in glance.
> Yup :)
>
>>> 4) Quotas and quota limits per domain. your instances in domain ‘a’ don’t count against quotas in domain ‘b’.
>> Yes we’ve talked about quotas for sure. This is definitely needed.
> Also: not really related to this, but if we're making considerable quota changes, I would also like to see the option for separate quotas _per flavor_, even. :)
>
>>> 5) Go as far as using different config values depending on what domain you’re using. This one is fun. :)
>> Curious for some examples here.
> With the idea that I want to be able to provide multiple virtual clouds within 1 big cloud, these virtual clouds may desire different config options. I'll pick one that could make sense:
>
> # When set, compute API will consider duplicate hostnames
> # invalid within the specified scope, regardless of case.
> # Should be empty, "project" or "global". (string value)
> #osapi_compute_unique_server_name_scope=
>
> This is the first one that popped into my mind for some reason, and it turns out that this is actually a more complicated example than I was originally intending. I left it here, because there might be a potential issue with this config option when using 'org.tenant' as project_id. Ignoring that, let's say this config option had a way to say "I don't want duplicate hostnames within my organization at all", "I don't want any single tenant in my organization to have duplicate hostnames", or "I don't care at all about duplicate hostnames". Ideally each organization could have its own config for this.
>
>>> volved with this. I am not sure that I currently have the time to help with implementation, however.
>> Come to the meeting on friday! 1600 UTC
> I meant to hit the first one. :-/   I'll try to hit it this week.
>
> - Chris
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list