openstack team mailing list archive
Mailing list archive
Re: Pondering multi-tenant needs in nova.
On 2/8/11 8:30 AM, Vishvananda Ishaya wrote:
> This thread is enormous, so I'm I'm going to briefly summarize the two options as I see them:
> 1. Project Id is an opaque string, and it simply represents some kind of collection of users. It is the
> responsibility of external systems (authn, authz, billing, and monitoring) to define what the string
> means, and what the relationships between the different "groups" and objects are. Nova needs a
> few plug-in points to authn and authz, but the logic relating these projects to users happens external
> to the nova code. Networking concerns are isolated to the project level.
> * Almost no changes to existing code (supporting multiple networks per project isonly necessary if
> we want to support multi-tenancy in vlan mode)
> * project code is simple and unencumbered (most small deployments don't need multi-tenancy)
This is not a Pro, this is a Con. We must design OpenStack around the
largest possible deployment while keeping the small ones in mind, not
the other way around.
Furthermore about multi-tenancy: a) Why are we thinking of multi-tenancy
as an optional component? It should be multi-tenancy by nature in that
any "tenant" can have a "sub-tenant". At some level don't we want a
supreme tenant that can control all others? In which case all it is is
tenants and sub-tenants.
Perhaps I am simply off base here in the relations between
tenants->Accounts->...->"Clouds(vms, network, storage services, etc.,
etc.)". Is this clearly defined now? If I am off base would someone be
so kind and educate this poor sole by pointing me to a link :)
> * pushing a lot of potentially useful code into external systems
> * potential for lack of code sharing between external sytsems
> 2. We change the project code into a more general concept of groups. Groups can contain other
> groups, and users and groups can be members of multiple groups. This would mirror the possibilities
> available in ldap.
> * Greater flexibility of implementation.
> * Group implementation code is in one place, minimizing different implementations per component
> * Much more complexity in the nova code.
> * The greater complexity/flexibility won't be needed for smaller deployments.
> Both of these options seem viable to me, but I'm actually leaning toward adding flexible groups into
> nova proper. A complete authentication system IMO needs to support, flexible groups. If we increase
> the flexibility of nova in this regard, it gives us a springboard to breaking out authz into a more complete
> separate service. I like this more than rewriting the entire thing from scratch as a completely new component.
> On Feb 8, 2011, at 8:11 AM, Jay Pipes wrote:
>> Hey Paul, yeah, see what happens when you take a little time away from email? ;P
>> So, I'm satisfied that I've highlighted the trade-offs that come along
>> with Nova not "inherently understanding the relationships between
>> Having an external system understand these account relationships is
>> fine, and the posters on this thread have done a good job explaining
>> the benefits that come along with federating the responsibility to an
>> external plugin/service, but there are some performance issues that
>> come along with it. However, as long as these inefficiencies are
>> known, I'm satisfied. :)
>> On Mon, Feb 7, 2011 at 11:37 PM, Paul Voccio <paul.voccio@xxxxxxxxxxxxx> wrote:
>>> Woah, seems I missed a lot by not being around email today.
>>> I was a bit confused at to why we would want to have nova trackif an
>>> account was being used by a reseller. In digging back through the
>>> blueprint associated with this, it seems the idea is for the operator (in
>>> this case Rackspace, but whoever) of Nova should track the idea of a
>>> reseller and accounts associated with that reseller. Nova itself would
>>> still retain the idea of a single account and the resources associated
>>> with that account. I guess this doesn't feel any different than another
>>> managed service provider who is doing add-on business on top of a amazon,
>>> rackspace, linode or other cloud business.
>>> While an operator *could* implement the account id as an arbitrary string
>>> and map inefficient queries to it as Jay mentions, I'm not sure they would
>>> (or even should).
>>> Jay -- I think I understand your concerns, but are you suggesting we
>>> implement the idea layer of resellers into Nova? Did I miss the point?
>>> Sorry if I'm late to the party on this one.
>>> On 2/7/11 8:20 PM, "Eric Day" <eday@xxxxxxxxxxxx> wrote:
>>>> On Mon, Feb 07, 2011 at 08:50:58PM -0500, Jay Pipes wrote:
>>>>> Eric, you and I have a database background. I know you understand that
>>>> Of course, but the first pair of queries is not as bad as a query
>>>> for every entity ID returned, which was in one of the previous emails
>>>> (the main thing I was trying to address).
>>>> There are other indexing tricks we can do as well, but lets not bother
>>>> pre-optimizing in email pseudo code. :)
>>>>> # Executed in the "auth service" or "configuration management
>>>>> database" as Jorge calls it:
>>>>> SELECT entity_id FROM entities
>>>>> WHERE user_id = <request.user_id>
>>>>> # Executed in the Nova database:
>>>>> SELECT * FROM instances
>>>>> JOIN instance_entity_map ON instance.id=instance_entity_map.instance_id
>>>>> WHERE instance_entity_map.entity_id in (<entity_ids>);
>>>>> is not the same as this:
>>>>> # Executed in the Nova database:
>>>>> SELECT * FROM instances
>>>>> JOIN instance_entity_map iem ON instance.id=iem.instance_id
>>>>> JOIN entities ON entities.entity_id = iem.entity_id
>>>>> JOIN users ON iem.user_id = <request.user_id> # This last join would,
>>>>> in practice, be a BETWEEN predicate on a self-join to the entities
>>>>> One query on a database versus two queries (one on each database).
>>>>> Let's not talk about distributed join flattening as if it somehow is a
>>>>> single query when in fact it isn't.
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help : https://help.launchpad.net/ListHelp
>>> Confidentiality Notice: This e-mail message (including any attached or
>>> embedded documents) is intended for the exclusive and confidential use of the
>>> individual or entity to which this message is addressed, and unless otherwise
>>> expressly indicated, is confidential and privileged information of Rackspace.
>>> Any dissemination, distribution or copying of the enclosed material is prohibited.
>>> If you receive this transmission in error, please notify us immediately by e-mail
>>> at abuse@xxxxxxxxxxxxx, and delete the original message.
>>> Your cooperation is appreciated.
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
Aimon Bustardo | Morph Labs | +1.310.625.0608 (mobile) | +1.310.437.4898 (office) | www.morphlabs.com | aimon@xxxxxx