inline: 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. > Pros: > * 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 :) Regards, Aimon > Cons: > * 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. > Pros: > * Greater flexibility of implementation. > * Group implementation code is in one place, minimizing different > implementations per component > Cons: > * 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. > > Vish > > > > 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 >> accounts". >> >> 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. :) >> >> Cheers! >> jay >> >> On Mon, Feb 7, 2011 at 11:37 PM, Paul Voccio <paul.voc...@rackspace.com> >> 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. >>> >>> https://blueprints.launchpad.net/nova/+spec/multi-tenant-accounting, >>> specifically: >>> >>> http://wiki.openstack.org/openstack-accounting?action=AttachFile&do=view&ta >>> rget=accounts.pdf >>> >>> 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. >>> >>> Pvo >>> >>> >>> On 2/7/11 8:20 PM, "Eric Day" <e...@oddments.org> 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 >>>>> this: >>>> 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. :) >>>> >>>> -Eric >>>> >>>>> # 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 >>>>> table >>>>> >>>>> 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. >>>>> >>>>> -jay >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~openstack >>>> Post to : openstack@lists.launchpad.net >>>> 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 ab...@rackspace.com, and delete the original message. >>> Your cooperation is appreciated. >>> >>> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > 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 | ai...@mor.ph _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp