Hi Patrick,
that would be great if you would go into details. I am most interested
in this as it directly effects our cloud platforms adoption of OpenStack
and the subsequent networking blueprint we have designed (trying to get
a hold of the networking blueprint Ewan is leading also).
Thank you,
Aimon,
You're correct of course for simply defining a customer per VLAN as
realistically we wouldn't hit 16M+ customers in any regional area as it stands
today ;) but there are other issues with QinQ at large scale, especially with
Layer 2 domains of the size that we're envisaging in the long
Hi Patrick, by using 802.1QiQ aren't we increasing the total VLAN count
to 4096*4096 (16277216) possible VLANS, each with the possibility of
using the same /8 network? In which case he in table storage of MACs is
the limiting factor.
Aimon
On 2/3/11 8:03 PM, Patrick Ancillotti wrote:
> Hey Guys,
Patrick,
You're right. I guess that¹s what I get for typing a response too fast.
Paul
On 2/3/11 10:03 PM, "Patrick Ancillotti"
wrote:
>Hey Guys,
>
>I think Paul may have gotten a bit mixed up between VLAN and CAM tables
>on switches. The VLAN part of an ethernet frame is 12 bits (0 - 4095)
>
Hey Guys,
I think Paul may have gotten a bit mixed up between VLAN and CAM tables on
switches. The VLAN part of an ethernet frame is 12 bits (0 - 4095) which limits
it accordingly. CAM tables however are a limit within switching gear that lists
the MAC addresses and their respective source and
I think Glen is on the right track here. Having the account_ID be a string
with no connotation for Nova allows two benefits: 1) deployments can create
the arbitrary organizational models that fit their particular DC, physical,
and logical structures, and 2) the Nova code is simpler as the hierarchi
On 2/3/11 2:02 PM, Devin Carlen wrote:
We were just talking about this the other day. We definitely need
some kind of further hierarchy. I think a typical kind of use case
for multi-tenant could be something like:
Enterprise contains Organizations
Organizations contain Organizations and Pro
Would a less structured approach work to make billing/reporting more flexible
for the community? I was thinking something along the lines of tags. With an
arbitrary set of tags, instances could have a tag saying they belong to a
certain organisation and/or an enterprise.
Reports could be gener
> There's no good reason for Nova to have to model an organization internally;
> it certainly wouldn't match all the possible org structures available.
+1
From: Devin Carlen mailto:devin.car...@gmail.com>>
Date: Thu, 3 Feb 2011 12:02:38 -0800
To: Monsyne Dragon mailto:mdra...@rackspace.com>>
C
Sandy, Devin,
this is structure we had in my former cloud platform to fit easily in
a LDAP. It also helped in metering.
Diego
-
Diego Parrilla
nubeblog.com | nubeb...@nubeblog.com | twitter.com/nubeblog
+34 649 94 43 29
On Thu, Feb 3, 2011 at 9:29 PM, Sandy Walsh wrote:
> Sounds very LDAP.
I think that this could be done in the current proposal. Specifically, the
account_id is an arbitrary string that is generated externally to Nova. You
could, for example, easily identify an organizational hierarchy. For example,
an accountID could be:
enterprise-org-project-milestone
>From Nov
Sounds very LDAP.
Would it make sense to have a plug-in so we could mimic a pre-existing corp
LDAP structure?
-S
From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of
We were just talking about this the other day. We definitely need some kind of
further hierarchy. I think a typical kind of use case for multi-tenant could
be something like:
Enterprise contains Organizations
Organizations contain Organizations and Projects
Projects contain Instances, etc.
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" wrote:
>If I'm not mistaken, VLAN networking *is* a first cla
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 multip
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/
++ on all below points :) There are few bugs or blueprints that
actually require a huge patch. Most things can be done in small
chunks, making sure each chunk doesn't break tests...
-jay
On Thu, Feb 3, 2011 at 10:03 AM, Ed Leafe wrote:
> On Feb 3, 2011, at 9:33 AM, Ewan Mellor wrote:
>
>> Maybe
On Feb 3, 2011, at 9:33 AM, Ewan Mellor wrote:
> Maybe we should normally do big-picture merges normally, but have an
> exception procedure for when we'd like them piecemeal.
I think the main differentiator should be if the partial merge can
stand on its own. IOW, with something like t
> -Original Message-
> From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net
> [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net]
> On Behalf Of Ed Leafe
> Sent: 03 February 2011 14:18
> To: openstack@lists.launchpad.net
> Subject: Re: [Openstack] Network Ser
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
On Feb 3, 2011, at 8:52 AM, Jay Pipes wrote:
>> Absolutely not, as long as we're not trying to merge conflicting branches.
>> That was the problem last time -- I18N and the logging changes in particular
>> were such pervasive pieces of work that it was hard work merging all the
>> time. Hopef
On Thu, Feb 3, 2011 at 8:46 AM, Ewan Mellor wrote:
>> -Original Message-
>> From: Jay Pipes [mailto:jaypi...@gmail.com]
>> Sent: 03 February 2011 13:40
>> To: Armando Migliaccio
>> Cc: Ewan Mellor; Andy Smith; Rick Clark; Søren Hansen;
>> openstack@lists.launchpad.net
>> Subject: Re: [Open
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
t
> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: 03 February 2011 13:40
> To: Armando Migliaccio
> Cc: Ewan Mellor; Andy Smith; Rick Clark; Søren Hansen;
> openstack@lists.launchpad.net
> Subject: Re: [Openstack] Network Service for L2/L3 Network
> Infrastructure b
2011/2/3 Diego Parrilla Santamaría :
> 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.
I don't
On Thu, Feb 3, 2011 at 4:28 AM, Armando Migliaccio
wrote:
> I second what Ewan said about the coding style in nova.virt.xenapi. I was
> responsible for part of refactoring and I am no longer fond of it either. I
> still think that it was good to break xenapi.py down as we did, but with
> hindsight
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
On Thu, 03 Feb 2011 10:30:17 +0100
Thierry Carrez wrote:
> Hello everyone,
>
> It is my great pleasure to announce the direct availability of the
> second release of the OpenStack project, codenamed "Bexar".
For those that want to try OpenStack on openSUSE or SLES and are a bit
adventurous, the
Hello everyone,
It is my great pleasure to announce the direct availability of the
second release of the OpenStack project, codenamed "Bexar".
The release consists of the following deliverables:
Swift 1.2.0: https://launchpad.net/swift/1.2/1.2.0
Nova 2011.1: https://launchpad.net/nova/bexar/2011
I second what Ewan said about the coding style in nova.virt.xenapi. I was
responsible for part of refactoring and I am no longer fond of it either. I
still think that it was good to break xenapi.py down as we did, but with
hindsight I would like to revise some of the choices made, and make the c
30 matches
Mail list logo
