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:
On Thu, 03 Feb 2011 10:30:17 +0100
Thierry Carrez thie...@openstack.org 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
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
2011/2/3 Diego Parrilla Santamaría diego.parrilla.santama...@gmail.com:
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:
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
On Thu, Feb 3, 2011 at 8:46 AM, Ewan Mellor ewan.mel...@eu.citrix.com 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
-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 Service
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
++ 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 e...@leafe.com wrote:
On Feb 3, 2011, at 9:33 AM, Ewan Mellor
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 devin.car...@gmail.commailto:devin.car...@gmail.com
Date: Thu, 3 Feb 2011 12:02:38 -0800
To: Monsyne Dragon
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
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
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
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
14 matches
Mail list logo
