> From: "Sean M. Collins" <s...@coreitpro.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > 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 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/ 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. 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
