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" <[email protected]>
To: "OpenStack Development Mailing List (not for usage questions)"
<[email protected]>
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 <[email protected]> wrote:
On Feb 5, 2014, at 12:27 AM, Chris Behrens <[email protected]> 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
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
