Open Stack

> From: "Sean M. Collins" <sean at coreitpro.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev at lists.openstack.org>
> Date: 10/12/2015 11:34 AM
> Subject: Re: [openstack-dev] [devstack] [neutron] A larger batch of 
> questions about configuring DevStack to use Neutron
> 
> On Thu, Oct 08, 2015 at 01:47:31PM EDT, Mike Spreitzer wrote:
> > ..
> > > > In the section 
> > > > http://docs.openstack.org/developer/devstack/guides/
> > > neutron.html#using-neutron-with-a-single-interface
> > > > there is a helpful display of localrc contents.  It says, among 
other 
> > > > things,
> > > > 
> > > >        OVS_PHYSICAL_BRIDGE=br-ex
> > > >        PUBLIC_BRIDGE=br-ex
> > > > 
> > > > In the next top-level section, 
> > > > http://docs.openstack.org/developer/devstack/guides/
> > > neutron.html#using-neutron-with-multiple-interfaces
> > > > , there is no display of revised localrc contents and no mention 
of 
> > > > changing either bridge setting.  That is an oversight, right?
> > > 
> > > No, this is deliberate. Each section is meant to be independent, 
since
> > > each networking configuration and corresponding DevStack 
configuration
> > > is different. Of course, this may need to be explicitly stated in 
the
> > > guide, so there is always room for improvement.
> > 
> > I am not quite sure I understand your answer.  Is the intent that I 
can 
> > read only one section, ignore all the others, and that will tell me 
how to 
> > use DevStack to produce that section's configuration?  If so then it 
would 
> > 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
> started pushing patches to correct this.
> 
> 
> > 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 

> > tried creating a VM connected to the public network, and that failed 
for 
> > lack of a Neutron DHCP server there.
> 
> The public network is used for floating IPs. The L3 agent creates NAT
> rules to intercept traffic on the public network and NAT it back to a
> guest instance that has the floating IP allocated to it.
> 
> The behavior for when a guest is directly attached to the public
> network, I sort of forget what happens exactly but I do know that it
> doesn't work from experience - most likely because the network is not
> 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.  Would you 
want 
> > that in this section --- in which case this section needs to specify 
that 
> > the provider DOES NOT already have DHCP service on the hardware 
network 
> > --- or as a new section?
> 
> No, I think we should maybe have a warning or something that the
> external network will be used for Floating IPs, and that guest instances
> should not be directly attached to that network.
> 
> > > > 
> > > > Looking at 
> > > > 
http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html(or
> > , in 
> > > > former days, the doc now preserved at 
> > > > http://docs.ocselected.org/openstack-manuals/kilo/networking-
> > > guide/content/under_the_hood_openvswitch.html
> > > > ) I see the name br-ex used for $PUBLIC_BRIDGE--- not 
> > $OVS_PHYSICAL_BRIDGE
> > > > , right?  Wouldn't it be less confusing if 
> > > > 
http://docs.openstack.org/developer/devstack/guides/neutron.htmlused a 
> > 
> > > > name other than "br-ex" for the exhibited commands that apply to 
> > > > $OVS_PHYSICAL_BRIDGE?
> > > 
> > > No, this is deliberate - br-ex is the bridge that is used for 
external
> > > network traffic - such as floating IPs and public IP address ranges. 
On
> > > the network node, a physical interface is attached to br-ex so that
> > > traffic will flow.
> > > 
> > > PUBLIC_BRIDGE is a carryover from DevStack's Nova-Network support 
and is
> > > 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
> > > PUBLIC_BRIDGE and OVS_PHYSICAL_BRIDGE is just a symptom.
> > 
> > Ah, thanks, that helps.  But I am still confused.  When using Neutron 
with 
> > two interfaces, there will be a bridge for each.
> 
> There shouldn't be. I'm pushing patches in the multiple interface
> section that includes output from the ovs-vsctl commands, hopefully
> it'll clarify things.
> 
> 
> > I have learned that 
> > DevStack will automatically create one bridge, and seen that it is 
named 
> > "br-ex" when following the instructions in the single-interface 
section. 
> > Now in the multiple-interface section I see that I should create a 
bridge 
> > named "br-ex" before invoking DevStack.
> 
> It should still create the bridge br-ex automatically. Depending on your
> configuration, DevStack should also attach the interface to the bridge
> automatically.
> 
> > I suppose DevStack will create 
> > the other bridge needed, but suspect I am missing a clue about what to 

> > tell DevStack so that it makes a bridge with the right name and 
connected 
> > to the right interface.
> 
> I don't believe a second bridge is required.
> 
> > Good.  I was afraid somebody would tell me there is no point in using 
OVS 
> > in a single-node setup.  I will revisit this after settling the issues 

> > above.
> 
> Eventually I'll get around to writing a LinuxBridge guide. Maybe after
> Tokyo.
> 
> Take a look at some of the patches I'm pushing, I do agree that the
> Neutron guide for DevStack got a little disjointed recently, and wasn't
> as clear as it needs to be. This is my fault, and I need to fix.
> Hopefully the patches that I'm pushing now will help. Please review!
> 
> https://review.openstack.org/#/c/233674
> 
> https://review.openstack.org/#/c/233666/

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?

I have not had a chance to test yet, but hope to do so soon.

Thanks,
Mike



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151013/9e777554/attachment.html>