<tt><font size=2>> From: "Sean M. Collins" <sean@coreitpro.com></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/12/2015 11:34 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>> 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 tell

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

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

> > contents. >  > 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  > > 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<br>> external router.<br>> <br>> > I am going to work out how to change <br>> > that, and am willing to contribute an update to this doc.  Would

you 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.htmlused><tt><font size=2>http://docs.openstack.org/developer/devstack/guides/neutron.htmlused</font></tt></a><tt><font size=2>a <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 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 create

a 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></font></tt><br><tt><font size=2>Thanks, those helped.  I reviewed them both,

and posted some notes to both --- even though the second has already merged.

 Perhaps another update is in order?</font></tt><br><br><tt><font size=2>I have not had a chance to test yet, but hope to do

so soon.</font></tt><br><br><tt><font size=2>Thanks,</font></tt><br><tt><font size=2>Mike</font></tt><br><br><BR>