Open Stack

Hi,

I have added the following section to the bug report,

-------
In the following quantum command,

quantum net-create --tenant-id $TENANT_ID net1 --provider:network_type vlan --provider:physical_network physnet1 --provider:segmentation_id 1024

provider:segmentation_id is actually a VLAN id which is used in the network for controller and compute nodes. This same VLAN id is also passed to the physical switch that interconnects controller and compute nodes. Try to avoid use VLAN id 1 since some physical switches do not forward VLAN 1 frames by default.
------

Thanks.

Dennis Qin

From: openstack-bounces+xiaohong.qin=emc.com at lists.launchpad.net [mailto:openstack-bounces+xiaohong.qin=emc.com at lists.launchpad.net] On Behalf Of Jasper Aikema
Sent: Thursday, October 18, 2012 3:12 PM
To: openstack at lists.launchpad.net
Subject: Re: [Openstack] Quantum features in the folsom release

Hello all,

I did report a bug about the lack of good documentation of quantum and provider routing.

If you find the solution, can you add it to the bug report? Maybe I can write a 'fix' for it.

The bug number is #1066782

Kind regards,

Jasper Aikema
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 at lists.launchpad.net<mailto:openstack-bounces+xiaohong.qin=emc.com at lists.launchpad.net> [mailto:openstack-bounces+xiaohong.qin=emc.com at lists.launchpad.net] On Behalf Of Mohammad Banikazemi
Sent: Thursday, October 18, 2012 6:15 AM
To: Dan Wendlandt
Cc: openstack-bounces+mb=us.ibm.com at lists.launchpad.net<mailto:openstack-bounces+mb=us.ibm.com at lists.launchpad.net>; openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
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.

[cid:image001.gif at 01CDB2B2.2C6D5D20]Dan Wendlandt ---09/10/2012 02:43:07 PM---On Mon, Sep 10, 2012 at 11:07 AM, Bilel Msekni <skible at hotmail.fr<mailto:skible at hotmail.fr>> wrote: > Hi Stackers,

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

________________________________



On Mon, Sep 10, 2012 at 11:07 AM, Bilel Msekni <skible at hotmail.fr<mailto:skible at hotmail.fr>> 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<https://launchpad.net/%7Eopenstack>
> Post to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack>
> More help   : https://help.launchpad.net/ListHelp



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com<http://www.nicira.com>
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

_______________________________________________
Mailing list: https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack>
Post to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
Unsubscribe : https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack>
More help   : https://help.launchpad.net/ListHelp




_______________________________________________

Mailing list: https://launchpad.net/~openstack

Post to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>

Unsubscribe : https://launchpad.net/~openstack

More help   : https://help.launchpad.net/ListHelp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20121025/e525d84d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 105 bytes
Desc: image001.gif
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20121025/e525d84d/attachment.gif>