> From: Mike Spreitzer/Watson/IBM@IBMUS > To: "OpenStack Development Mailing List \(not for usage questions\)" > <[email protected]> > 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" <[email protected]> > > To: "OpenStack Development Mailing List (not for usage questions)" > > <[email protected]> > > 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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
