If I'm not mistaken, VLAN networking *is* a first class citizen in Nova. It's the Flat Networking model which isn't a first-class citizen, and thus the need for support in things such as this:
IPv6 is not supported in FlatManager network mode. You can't use FlatDHCPManager network mode on a multiple machines deployment without using multiple interfaces (Bug 710959). Recommended mode of operation for deploying Nova on multiple machines is to use VLAN-supporting managed switches with VlanManager network mode. ^^ is from the Bexar release notes. -jay 2011/2/3 Carl Fischer <[email protected]>: > Diego is definitely correct. The drawbacks with VLANs are well documented > but they remain the primary solution for providing per-tenant L2 domains > for many shops today, due to skill set, comfort level, etc. The > L3-integrated solutions on the horizon will be vast improvements, but > until they arrive/mature we need to ensure the VLAN model is a first class > citizen. > > Carl > Citrix Systems > [email protected] > > On 2/3/11 6:32 AM, "Diego Parrilla Santamaría" > <[email protected]> wrote: > >>Thanks Paul. Your explanation really helps. A vlan is a scarce >>resource in cloud infraestructures and most of the people don't know >>about it. >> >>I asked about this topic in this thread because I see two different >>approaches that colides. And can have a huge impact in the 'account' >>entity. >> >>The truth is that most of the datacenter professionals I have talked >>about reject the Flat Network model and embrace the VLAN (or more than >>one VLAN) per customer model because it is what they know and they >>feel 'secured' using them. Openstack let us choose what model to use, >>and this great and I think should not change. So, creating an account >>entitty directly linked to the network model is dangerous because it >>can limit this flexibility. >> >>I know, I have not given any valid answer... but it's something to >>consider due to the efforts to support a more complex network >>management. >> >>Cheers >>Diego >> >>- >>Diego Parrilla >>nubeblog.com | [email protected] | twitter.com/nubeblog >>+34 649 94 43 29 >> >> >> >> >>2011/2/3 Paul Voccio <[email protected]>: >>> Diego, >>> >>> Due to our networking topology, having a vlan per customer isn't really >>> feasible. Most switches are limited at 4k or 8k or even 32k. With more >>> customers than these switches can reasonably accommodate, having a >>>single >>> vlan per customer either limits the portability within a cloud or limits >>> the scale at which you can build your cloud. Open vSwitch will alleviate >>> some of this pain, but until we get it in XenServer, we're somewhat >>>stuck >>> on flat networking. >>> >>> Paul >>> >>> On 2/3/11 4:20 AM, "Diego Parrilla Santamaría" >>> <[email protected]> wrote: >>> >>>>Hi Monsyne, >>>> >>>>it's a very interesting topic and I'm curious about the reason why you >>>>are using the Flat Networking set up. From the conversations in other >>>>threads it seems the Service Providers prefer different networking >>>>approaches: VLAN oriented basically. >>>> >>>>Regards >>>>Diego >>>> >>>>- >>>>Diego Parrilla >>>>nubeblog.com | [email protected] | twitter.com/nubeblog >>>>+34 649 94 43 29 >>>> >>>> >>>> >>>> >>>>On Thu, Feb 3, 2011 at 2:37 AM, Monsyne Dragon <[email protected]> >>>>wrote: >>>>> I am sorting out some possible implementations for the >>>>> multi-tenant-accounting blueprint, and the related >>>>>system-usage-records >>>>>bp, >>>>> and I just wanted to run this by anyone interested in such matters. >>>>> >>>>> Basically, for multitenant purposes we need to introduce the concept >>>>>of >>>>>an >>>>> 'account' in nova, representing a customer, that basically acts as a >>>>>label >>>>> for a group of resources (instances, etc), and for access control (i.e >>>>> customer a cannot mess w/ customer b's stuff) >>>>> >>>>> There was some confusion on how best to implement this, in relation to >>>>> nova's project concept. Projects are kind of like what we want an >>>>>account >>>>> to be, but there are some associations (like one project per network) >>>>>which >>>>> are not valid for our flat networking setup. I am kind of >>>>>straw-polling on >>>>> which is better here: >>>>> >>>>> The options are: >>>>> 1) Create a new 'account' concept in nova, with an account basically >>>>>being >>>>> a subgroup of a project (providers would use a single, default >>>>>project, >>>>>with >>>>> additional projects added if needed for separate brands, or resellers, >>>>>etc), >>>>> add in access control per account as well as project, and make sure >>>>> apis/auth specify account appropriately, have some way for a default >>>>> account to used (per project) so account doesn't get in the way for >>>>> non-multitenant users. >>>>> >>>>> 2) having account == nova's "project", and changing the network >>>>> associations, etc so projects can support our model (as well as >>>>>current >>>>> models). Support for associating accounts (projects) together for >>>>> resellers, etc would either be delegated outside of nova or added >>>>>later >>>>> (it's not a current requirement). >>>>> >>>>> In either case, accounts would be identified by name, which would be >>>>>an >>>>> opaque string an outside system/person would assign, and could >>>>>structure to >>>>> their needs (ie. for associating accounts with common prefixes, etc) >>>>> >>>>> -- >>>>> >>>>> -- >>>>> -Monsyne Dragon >>>>> work: 210-312-4190 >>>>> mobile 210-441-0965 >>>>> google voice: 210-338-0336 >>>>> >>>>> >>>>> >>>>> 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 [email protected], and delete the original message. >>>>> Your cooperation is appreciated. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~openstack >>>>> Post to : [email protected] >>>>> Unsubscribe : https://launchpad.net/~openstack >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>> >>>>_______________________________________________ >>>>Mailing list: https://launchpad.net/~openstack >>>>Post to : [email protected] >>>>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 [email protected], and delete the original message. >>> Your cooperation is appreciated. >>> >>> >> >>_______________________________________________ >>Mailing list: https://launchpad.net/~openstack >>Post to : [email protected] >>Unsubscribe : https://launchpad.net/~openstack >>More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
