On Feb 5, 2014, at 3:38 AM, Vishvananda Ishaya <vishvana...@gmail.com> wrote:
> > On Feb 5, 2014, at 12:27 AM, Chris Behrens <cbehr...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
