openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

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
>