openstack team mailing list archive

[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