<tt><font size=2>> From: "Sean M. Collins" <sean@coreitpro.com></font></tt><br><tt><font size=2>...</font></tt><br><tt><font size=2>> <br>> On Tue, Oct 06, 2015 at 11:25:03AM EDT, Mike Spreitzer wrote:<br>> > [Sorry, but I do not know if the thundering silence is because
these <br>> > questions are too hard, too easy, grossly off-topic, or simply
because <br>> > nobody cares.]<br>> <br>> You sent your first e-mail on a Saturday. I saw it and flagged it
for<br>> reply, but have not had a chance yet. It's only Tuesday. I do care
and<br>> your questions are important. I will say though that it's a little<br>> difficult to answer your e-mail because of formatting and your thoughts<br>> seem to jump around. This is not intended as a personal criticism,
it's<br>> just a little difficult to follow your e-mail in order to reply.</font></tt><br><br><tt><font size=2>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.</font></tt><br><tt><font size=2><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.</font></tt><br><br><tt><font size=2>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 </font></tt><a href="http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-multiple-interfaces"><tt><font size=2 color=blue>http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-multiple-interfaces</font></tt></a><tt><font size=2>does not display any localrc contents at all.</font></tt><br><br><tt><font size=2>> For example, There needs<br>> to be some editing done for that doc - the part about disabling the<br>> firewall is just dropped in the middle of the doc and breaks the flow
-<br>> among other things. This is obviously not helpful to a new reader
and we<br>> need to fix.<br>> <br>> <br>> > I am <br>> > guessing I need to set OVS_PHYSICAL_BRIDGEand PUBLIC_BRIDGEto
different <br>> > values, and the exhibited `ovs-vsctl` commands in this section
apply to <br>> > $OVS_PHYSICAL_BRIDGE. Is that right? Are there other
revisions I need to <br>> > make to localrc?<br>> <br>> No, this is not correct.<br>> <br>> What does your networking layout look like on the DevStack node that
you<br>> are trying to configure?</font></tt><br><br><tt><font size=2>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?</font></tt><br><tt><font size=2><br>> <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>,
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 $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>> > 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<br>> Neutron support, for the Open vSwitch driver specifically. They are
two<br>> variables that for the most part serve the same purpose. Frankly,<br>> DevStack has a lot of problems with configuration knobs, and<br>> PUBLIC_BRIDGE and OVS_PHYSICAL_BRIDGE is just a symptom.</font></tt><br><br><tt><font size=2>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.</font></tt><br><tt><font size=2><br>> <br>> <br>> > 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#neutron-networking-with-open-vswitch<br>> > builds on <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>> > NOT <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>> > --- right? Could I stop after reading that section, or
must I go on to <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#neutron-networking-with-open-vswitch-and-provider-networks<br>> <br>> See my previous statement - each section is supposed to be independent.</font></tt><br><br><tt><font size=2>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.</font></tt><br><tt><font size=2><br>> <br>> > ?<br>> > <br>> > The exhibited localrc contents in 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>> > include both of these:<br>> > <br>> > Q_L3_ENABLED=True<br>> > Q_USE_PROVIDERNET_FOR_PUBLIC=True<br>> <br>> Yes they do. They are there for a reason, it's how to configure DevStack<br>> in such a way that you end up with a network configuration in Neutron<br>> that fits the diagram that is shown in the section.<br>> <br>> <br>> <br>> > <br>> > and nothing gainsays either of them until 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#neutron-networking-with-open-vswitch-and-provider-networks<br>> > --- where we first see<br>> > <br>> > Q_L3_ENABLED=False<br>> > <br>> > Is it true that all the other sections want both Q_L3_ENABLEDand
<br>> > Q_USE_PROVIDERNET_FOR_PUBLICto be True?<br>> <br>> No. If they are omitted from the other sections, that is intentional.<br>> <br>> > <br>> > I tried adding IPv6 support to the recipe of the first 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>> > ). I added this to my localrc:<br>> > <br>> > IP_VERSION=4+6<br>> > IPV6_PUBLIC_RANGE=fddf:2::/64<br>> > IPV6_PUBLIC_NETWORK_GATEWAY=fddf:2::1<br>> > IPV6_ROUTER_GW_IP=fddf:2::231<br>> > <br>> > At first I had tried setting a different set of IPv6 variables
(having <br>> > only IP_VERSION in common with what I exhibit here), but found
those: (a) <br>> > duplicated the defaults and (b) caused problems due to lack of
the ones I <br>> > mention here. Even the ones mentioned here led to a problem.
There is a <br>> > bit of scripging that replaces my setting for IPV6_ROUTER_GW_IP
with <br>> > something dug out of Neutron. That went wrong. It
replaced my setting <br>> > with fddf:2::2, but that address was already in use by something
else.<br>> <br>> OK - I'm not sure what your networking layout is like on your DevStack<br>> node, and frankly I think we need to back up and determine that before<br>> we go into IPv6.</font></tt><br><br><tt><font size=2>Agreed.</font></tt><br><br><tt><font size=2>Thanks,</font></tt><br><tt><font size=2>Mike</font></tt><br><br><BR>