[openstack-dev] [devstack] [neutron] A larger batch of questions about configuring DevStack to use Neutron

Mike Spreitzer mspreitz at us.ibm.com
Thu Oct 8 17:47:31 UTC 2015

> From: "Sean M. Collins" <sean at coreitpro.com>
> On Tue, Oct 06, 2015 at 11:25:03AM EDT, Mike Spreitzer wrote:
> > [Sorry, but I do not know if the thundering silence is because these 
> > questions are too hard, too easy, grossly off-topic, or simply because 

> > nobody cares.]
> You sent your first e-mail on a Saturday. I saw it and flagged it for
> reply, but have not had a chance yet. It's only Tuesday. I do care and
> your questions are important. I will say though that it's a little
> difficult to answer your e-mail because of formatting and your thoughts
> seem to jump around. This is not intended as a personal criticism, it's
> just a little difficult to follow your e-mail in order to reply.

Thanks, I am glad somebody cares.  I used different subject lines because 
I was suspecting that I did not flag them correctly.  I see now that I was 
just too impatient.

> > 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.  OTOH, if some sections build on other sections, it would be 
good if the dependent sections display the localrc contents that differ. 
Right now, the section at 
does not display any localrc contents at all.

> For example, There needs
> to be some editing done for that doc - the part about disabling the
> firewall is just dropped in the middle of the doc and breaks the flow -
> among other things. This is obviously not helpful to a new reader and we
> need to fix.
> > I am 
> > guessing I need to set OVS_PHYSICAL_BRIDGEand PUBLIC_BRIDGEto 
> > values, and the exhibited `ovs-vsctl` commands in this section apply 
> > $OVS_PHYSICAL_BRIDGE.  Is that right?  Are there other revisions I 
need to 
> > make to localrc?
> No, this is not correct.
> What does your networking layout look like on the DevStack node that you
> are trying to configure?

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.  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?

> > 
> > 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 
> > , 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 
> 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.  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.  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.

> > The section 
> > http://docs.openstack.org/developer/devstack/guides/
> neutron.html#neutron-networking-with-open-vswitch
> > builds on 
> > http://docs.openstack.org/developer/devstack/guides/
> neutron.html#using-neutron-with-multiple-interfaces
> > NOT 
> > http://docs.openstack.org/developer/devstack/guides/
> neutron.html#using-neutron-with-a-single-interface
> > --- right?  Could I stop after reading that section, or must I go on 
> > http://docs.openstack.org/developer/devstack/guides/
> neutron.html#neutron-networking-with-open-vswitch-and-provider-networks
> See my previous statement - each section is supposed to be independent.

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 

> > ?
> > 
> > The exhibited localrc contents in section 
> > http://docs.openstack.org/developer/devstack/guides/
> neutron.html#using-neutron-with-a-single-interface
> > include both of these:
> > 
> >        Q_L3_ENABLED=True
> Yes they do. They are there for a reason, it's how to configure DevStack
> in such a way that you end up with a network configuration in Neutron
> that fits the diagram that is shown in the section.
> > 
> > and nothing gainsays either of them until section 
> > http://docs.openstack.org/developer/devstack/guides/
> neutron.html#neutron-networking-with-open-vswitch-and-provider-networks
> > --- where we first see
> > 
> >        Q_L3_ENABLED=False
> > 
> > Is it true that all the other sections want both Q_L3_ENABLEDand 
> No. If they are omitted from the other sections, that is intentional.
> > 
> > I tried adding IPv6 support to the recipe of the first section (
> > http://docs.openstack.org/developer/devstack/guides/
> neutron.html#using-neutron-with-a-single-interface
> > ).  I added this to my localrc:
> > 
> >         IP_VERSION=4+6
> >         IPV6_PUBLIC_RANGE=fddf:2::/64
> >         IPV6_PUBLIC_NETWORK_GATEWAY=fddf:2::1
> >         IPV6_ROUTER_GW_IP=fddf:2::231
> > 
> > At first I had tried setting a different set of IPv6 variables (having 

> > only IP_VERSION in common with what I exhibit here), but found those: 
> > duplicated the defaults and (b) caused problems due to lack of the 
ones I 
> > mention here.  Even the ones mentioned here led to a problem.  There 
is a 
> > bit of scripging that replaces my setting for IPV6_ROUTER_GW_IP with 
> > something dug out of Neutron.  That went wrong.  It replaced my 
> > with fddf:2::2, but that address was already in use by something else.
> OK - I'm not sure what your networking layout is like on your DevStack
> node, and frankly I think we need to back up and determine that before
> we go into IPv6.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151008/665ea67c/attachment-0001.html>

More information about the OpenStack-dev mailing list