<tt><font size=2>> From: Mike Spreitzer/Watson/IBM@IBMUS</font></tt><br><tt><font size=2>> To: "OpenStack Development Mailing List

\(not for usage questions\)"<br>> <openstack-dev@lists.openstack.org></font></tt><br><tt><font size=2>> Date: 10/13/2015 03:39 AM</font></tt><br><tt><font size=2>> Subject: Re: [openstack-dev] [devstack] [neutron]

A larger batch of <br>> questions about configuring DevStack to use Neutron</font></tt><br><tt><font size=2>> <br>> > From: "Sean M. Collins" <sean@coreitpro.com><br>> > To: "OpenStack Development Mailing List (not for usage questions)"

<br>> > <openstack-dev@lists.openstack.org><br>> > Date: 10/12/2015 11:34 AM<br>> > Subject: Re: [openstack-dev] [devstack] [neutron] A larger batch

of <br>> > questions about configuring DevStack to use Neutron<br>> > <br>> > On Thu, Oct 08, 2015 at 01:47:31PM EDT, Mike Spreitzer wrote:<br>> > > ..<br>> > > > > In the section <br>> > > > > </font></tt><a href=http://docs.openstack.org/developer/devstack/guides/><tt><font size=2>http://docs.openstack.org/developer/devstack/guides/</font></tt></a><tt><font size=2><br>> > > > neutron.html#using-neutron-with-a-single-interface<br>> > > > > there is a helpful display of localrc contents.

 It says, among other <br>> > > > > things,<br>> > > > > <br>> > > > >        OVS_PHYSICAL_BRIDGE=br-ex<br>> > > > >        PUBLIC_BRIDGE=br-ex<br>> > > > > <br>> > > > > In the next top-level section, <br>> > > > > </font></tt><a href=http://docs.openstack.org/developer/devstack/guides/><tt><font size=2>http://docs.openstack.org/developer/devstack/guides/</font></tt></a><tt><font size=2><br>> > > > neutron.html#using-neutron-with-multiple-interfaces<br>> > > > > , there is no display of revised localrc contents

and no mention of <br>> > > > > changing either bridge setting.  That is

an oversight, right?<br>> > > > <br>> > > > No, this is deliberate. Each section is meant to be

independent, since<br>> > > > each networking configuration and corresponding DevStack

configuration<br>> > > > is different. Of course, this may need to be explicitly

stated in the<br>> > > > guide, so there is always room for improvement.<br>> > > <br>> > > I am not quite sure I understand your answer.  Is the

intent that I can <br>> > > read only one section, ignore all the others, and that will

tellme how to <br>> > > use DevStack to produce that section's configuration?  If

so <br>> then it would <br>> > > be good if each section had a display of all the necessary

localrc <br>> > > contents.<br>> > <br>> > Agreed. This is a failure on my part, because I was pasting in

only > > parts of my localrc (since it came out of a live lab environment).

I've<br>> > started pushing patches to correct this.<br>> > <br>> > <br>> > > I have started over, from exactly the picture drawn at the

start of the <br>> > > doc.  That has produced a configuration that mostly

works.  However, I <br>> > > tried creating a VM connected to the public network, and

that failed for <br>> > > lack of a Neutron DHCP server there.<br>> > <br>> > The public network is used for floating IPs. The L3 agent creates

NAT<br>> > rules to intercept traffic on the public network and NAT it back

to a<br>> > guest instance that has the floating IP allocated to it.<br>> > <br>> > The behavior for when a guest is directly attached to the public<br>> > network, I sort of forget what happens exactly but I do know

that it<br>> > doesn't work from experience - most likely because the network

is not<br>> > configured as a flat network. It will not receive a DHCP lease

from the > > external router. > >  > > > I am going to work out how to change  > > > that, and am willing to contribute an update to this doc.

 Wouldyou want <br>> > > that in this section --- in which case this section needs

to specify that <br>> > > the provider DOES NOT already have DHCP service on the hardware

network <br>> > > --- or as a new section?<br>> > <br>> > No, I think we should maybe have a warning or something that

the<br>> > external network will be used for Floating IPs, and that guest

instances<br>> > should not be directly attached to that network.<br>> > <br>> > > > > <br>> > > > > Looking at <br>> > > > > </font></tt><a href="http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html(or"><tt><font size=2>http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html(or</font></tt></a><tt><font size=2><br>> > > , in <br>> > > > > former days, the doc now preserved at <br>> > > > > </font></tt><a href="http://docs.ocselected.org/openstack-manuals/kilo/networking-"><tt><font size=2>http://docs.ocselected.org/openstack-manuals/kilo/networking-</font></tt></a><tt><font size=2><br>> > > > guide/content/under_the_hood_openvswitch.html<br>> > > > > ) I see the name br-ex used for $PUBLIC_BRIDGE---

not <br>> > > $OVS_PHYSICAL_BRIDGE<br>> > > > > , right?  Wouldn't it be less confusing if

<br>> > > > > </font></tt><a href=http://docs.openstack.org/developer/devstack/guides/neutron.htmluseda><tt><font size=2>http://docs.openstack.org/developer/devstack/guides/neutron.htmluseda</font></tt></a><tt><font size=2><br>> > > <br>> > > > > name other than "br-ex" for the exhibited

commands that apply to <br>> > > > > $OVS_PHYSICAL_BRIDGE?<br>> > > > <br>> > > > No, this is deliberate - br-ex is the bridge that is

used for external<br>> > > > network traffic - such as floating IPs and public IP

address ranges. On<br>> > > > the network node, a physical interface is attached

to br-ex so that<br>> > > > traffic will flow.<br>> > > > <br>> > > > PUBLIC_BRIDGE is a carryover from DevStack's Nova-Network

support and is<br>> > > > used in some places, with OVS_PHYSICAL_BRIDGE being

used by DevStack's > > > > Neutron support, for the Open vSwitch driver specifically.

They are two > > > > variables that for the most part serve the same purpose.

Frankly, > > > > DevStack has a lot of problems with configuration knobs,

and<br>> > > > PUBLIC_BRIDGE and OVS_PHYSICAL_BRIDGE is just a symptom.<br>> > > <br>> > > Ah, thanks, that helps.  But I am still confused.  When

using <br>> Neutron with <br>> > > two interfaces, there will be a bridge for each.<br>> > <br>> > There shouldn't be. I'm pushing patches in the multiple interface<br>> > section that includes output from the ovs-vsctl commands, hopefully<br>> > it'll clarify things.<br>> > <br>> > <br>> > > I have learned that <br>> > > DevStack will automatically create one bridge, and seen

that it is named <br>> > > "br-ex" when following the instructions in the

single-interface section. <br>> > > Now in the multiple-interface section I see that I should

createa bridge <br>> > > named "br-ex" before invoking DevStack.<br>> > <br>> > It should still create the bridge br-ex automatically. Depending

on your<br>> > configuration, DevStack should also attach the interface to the

bridge<br>> > automatically.<br>> > <br>> > > I suppose DevStack will create <br>> > > the other bridge needed, but suspect I am missing a clue

about what to <br>> > > tell DevStack so that it makes a bridge with the right name

and connected <br>> > > to the right interface.<br>> > <br>> > I don't believe a second bridge is required.<br>> > <br>> > > Good.  I was afraid somebody would tell me there is

no point in using OVS <br>> > > in a single-node setup.  I will revisit this after

settling the issues <br>> > > above.<br>> > <br>> > Eventually I'll get around to writing a LinuxBridge guide. Maybe

after<br>> > Tokyo.<br>> > <br>> > Take a look at some of the patches I'm pushing, I do agree that

the<br>> > Neutron guide for DevStack got a little disjointed recently,

and wasn't<br>> > as clear as it needs to be. This is my fault, and I need to fix.<br>> > Hopefully the patches that I'm pushing now will help. Please

review!<br>> > <br>> > </font></tt><a href=https://review.openstack.org/#/c/233674><tt><font size=2>https://review.openstack.org/#/c/233674</font></tt></a><tt><font size=2><br>> > <br>> > </font></tt><a href=https://review.openstack.org/#/c/233666/><tt><font size=2>https://review.openstack.org/#/c/233666/</font></tt></a><tt><font size=2><br>> <br>> Thanks, those helped.  I reviewed them both, and posted some

notes <br>> to both --- even though the second has already merged.  Perhaps

<br>> another update is in order?<br>> <br>> I have not had a chance to test yet, but hope to do so soon.<br></font></tt><br><tt><font size=2>Now I have tested the first section (taking the latest

of both changes) using stable/liberty, and it failed because br-ex was

not created automatically.  I opened </font></tt><a href="https://bugs.launchpad.net/devstack/+bug/1506733"><tt><font size=2 color=blue>https://bugs.launchpad.net/devstack/+bug/1506733</font></tt></a><br><br><tt><font size=2>I think Kilo did not have this problem.</font></tt><br><br><tt><font size=2>Thanks,</font></tt><br><tt><font size=2>Mike</font></tt><br><br><BR>