← Back to team overview

openstack team mailing list archive

Re: Quantum features in the folsom release

 

I have also tried it out in my lab by following steps documented in this
URL,

 

http://docs.openstack.org/trunk/openstack-network/admin/content/app_demo
.html

 

The floating IP address assigned to VM spawned off in controller node is
working from, however, for VMs spawned off on compute node, floating IP
address associated to them are not reachable from controller node or
anywhere else. I don't have a dedicated physical machine running as
network node; this node is combined into the controller node which is a
real physical machine. 

 

In the pages following the network diagram, the CLIs provided using
eth1, eth2 etc, but didn't associate these network interface names with
the three network links (mgmt net, data net, and public net) illustrated
in the diagram. So maybe I'm still missing magic CLIs here to get multi
node deployment working. Appreciate a lot if someone can shed some light
here.

 

Thanks.

 

Dennis Qin

 

From: openstack-bounces+xiaohong.qin=emc.com@xxxxxxxxxxxxxxxxxxx
[mailto:openstack-bounces+xiaohong.qin=emc.com@xxxxxxxxxxxxxxxxxxx] On
Behalf Of Mohammad Banikazemi
Sent: Thursday, October 18, 2012 6:15 AM
To: Dan Wendlandt
Cc: openstack-bounces+mb=us.ibm.com@xxxxxxxxxxxxxxxxxxx;
openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] Quantum features in the folsom release

 

Trying to setup something similar to the Demo Setup described on the
Openstack Quantum Admin Guide posted at: 
http://docs.openstack.org/trunk/openstack-network/admin/content/app_demo
.html. I am using devstack to do the installation. 

For the Network Node it says three network interfaces are required: 

>The node must have at least three network interfaces. The first is used
to communicate with the controller node,
>this is via the management network. The IP address of this interface
should be configured to 100.1.1.12/24.
>The second interface will be used for the VM traffic, this is on the
data network. The third interface will be used to
>connect to the external gateway on the network. This interface will be
bridged to the Open vSwitch bridge "br-ex" interface. 

1- Anyway we can set things up with only one or two interfaces? This is
a real requirement or just to make the demo setup easier to implement? 

2- Right now I only have two interfaces on my server and if I connect
either of them to br-ex my server (the node and all the VMs on it)
becomes unreachable. Right now I want to have only one single server for
my experiments so I really do not need the network for VM traffic. 

3- Is the br-eht1 bridge required for VM to VM communication is there to
deal with namespaces? Earlier all I had to do to connect VMs on the same
network together was to connect say eth1 directly to br-int. Now, there
is this additional br-eth1 that needs to be created. 

Thanks.

 Dan Wendlandt ---09/10/2012 02:43:07 PM---On Mon, Sep 10, 2012 at 11:07
AM, Bilel Msekni <skible@xxxxxxxxxx> wrote: > Hi Stackers,

From: Dan Wendlandt <dan@xxxxxxxxxx>
To: Bilel Msekni <skible@xxxxxxxxxx>, 
Cc: openstack@xxxxxxxxxxxxxxxxxxx
Date: 09/10/2012 02:43 PM
Subject: Re: [Openstack] Quantum features in the folsom release
Sent by: openstack-bounces+mb=us.ibm.com@xxxxxxxxxxxxxxxxxxx

________________________________




On Mon, Sep 10, 2012 at 11:07 AM, Bilel Msekni <skible@xxxxxxxxxx>
wrote:
> Hi Stackers,
>
> Can someone here help me out by detailing the new Quantum features
that will
> be available in the Folsom release. Even a link or anything could help
! i
> can't seem to find any proper documentation and i have to persuade my
boss
> about the potentials of Quantum :)

Hi Bilel,

Don't worry, the Quantum team is working hard on docs for Folsom as we
speak.

At an extremely high-level, the two main things that Quantum provides
are:

1) A rich tenant-facing API for defining networks.  This let's tenants
create rich network topologies, including multiple private networks,
multi-tier web applications, etc. and choose which IP subnets are used
on these networks (this even works if two tenants decide to use the
same subnet).

2)  Quantum has pluggable backends that allow cloud operators to use
more advanced network technologies on the back-end.  For example, you
can use Open vSwitch tunneling to avoid limitations around VLANs or
take advantage of a plugin that is aware of advanced hardware
capabilities.

The Quantum Admin Guide is still in draft form and we're hoping to
have a publicly consumable draft near the end of this week.  That
should provide the additional details about specific capabilities.

Dan


>
> Thanks
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp



GIF image


Follow ups

References