Open Stack

> From: Mike Spreitzer/Watson/IBM at IBMUS
> To: "OpenStack Development Mailing List \(not for usage questions\)"
> <openstack-dev at lists.openstack.org>
> Date: 10/13/2015 03:39 AM
> Subject: Re: [openstack-dev] [devstack] [neutron] A larger batch of 
> questions about configuring DevStack to use Neutron
> 
> > 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 tellme 
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.  Wouldyou 
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.htmluseda 
> > > 
> > > > > 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 createa 
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.

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 https://bugs.launchpad.net/devstack/+bug/1506733

I think Kilo did not have this problem.

Thanks,
Mike



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151016/97d99bfa/attachment.html>