Hi all, I am a bit concerned over what I am inferring about networking modes in OpenStack from this thread. Is it proposed that we will support only one mode per install/tenant/account/project/whatever? If so I believe this to be a very limited view of how this can/should work. Or is my inference wrong?
Aimon On 2/8/11 10:41 AM, Vishvananda Ishaya wrote: > 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 -- 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
