Open Stack

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/



-- 
Sean M. Collins