> From: "Sean M. Collins" <s...@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 http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-multiple-interfaces 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 different > > values, and the exhibited `ovs-vsctl` commands in this section apply to > > $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 $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. 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 to > > 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 above. > > > ? > > > > 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 > > Q_USE_PROVIDERNET_FOR_PUBLIC=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 > > Q_USE_PROVIDERNET_FOR_PUBLICto be True? > > 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: (a) > > 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 setting > > 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. Agreed. Thanks, Mike
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev