openstack team mailing list archive

[Carl Fischer <Carl.Fischer@xxxxxxxxxx>]

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" <jaypipes@xxxxxxxxx> 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 <Carl.Fischer@xxxxxxxxxx>:
>> 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
>> carl.fischer@xxxxxxxxxx
>>
>> On 2/3/11 6:32 AM, "Diego Parrilla Santamaría"
>> <diego.parrilla.santamaria@xxxxxxxxx> 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 | nubeblog@xxxxxxxxxxxx | twitter.com/nubeblog
>>>+34 649 94 43 29
>>>
>>>
>>>
>>>
>>>2011/2/3 Paul Voccio <paul.voccio@xxxxxxxxxxxxx>:
>>>> 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"
>>>> <diego.parrilla.santamaria@xxxxxxxxx> 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 | nubeblog@xxxxxxxxxxxx | twitter.com/nubeblog
>>>>>+34 649 94 43 29
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>On Thu, Feb 3, 2011 at 2:37 AM, Monsyne Dragon <mdragon@xxxxxxxxxxxxx>
>>>>>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 abuse@xxxxxxxxxxxxx, and delete the original message.
>>>>>> Your cooperation is appreciated.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~openstack
>>>>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>Mailing list: https://launchpad.net/~openstack
>>>>>Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>>>>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 abuse@xxxxxxxxxxxxx, and delete the original message.
>>>> Your cooperation is appreciated.
>>>>
>>>>
>>>
>>>_______________________________________________
>>>Mailing list: https://launchpad.net/~openstack
>>>Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>>Unsubscribe : https://launchpad.net/~openstack
>>>More help   : https://help.launchpad.net/ListHelp
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>