Right, I actually meant to say remains a first class citizen, agreeing with Diego as an adjunct to Paul's comment in case anyone interpreted his 100% valid point as a ding against the VLAN model.
Carl On 2/3/11 12:35 PM, "Jay Pipes" <[email protected]> wrote: >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
