Projects aren't associated with networks in any other mode. Networks are assigned by compute host.
Vish On Feb 8, 2011, at 10:15 AM, Paul Voccio wrote: > > > On 2/8/11 10:30 AM, "Vishvananda Ishaya" <vishvana...@gmail.com> 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) > > Won't we still have to support multiple networks per project in flat > networking as well? You could go into multiple zones, supported by > different networking gear that will need different networks routed to > them. > >> * project code is simple and unencumbered (most small deployments don't >> need multi-tenancy) >> 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. > > This seems like it is an issue only larger deployments of Nova will > encounter. Trying to guess how someone will try to implement and bill for > resellers and groups and which group should have access to another group's > resources seems almost out of scope at the moment. > > >> >> 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 >> > > > > 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
