Open Stack

Thanks, i will review soon.  BTW, i am interested in creating a config in which a Compute Instance can be created on an external network.

Thanks,
Mike




   Sean M. Collins --- Re: [openstack-dev] [devstack] [neutron] A larger batch of questions about configuring DevStack to use Neutron --- 
    From:"Sean M. Collins" <sean at coreitpro.com>To:"OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>Date:Mon, Oct 12, 2015 11:34Subject: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/ -- Sean M. Collins __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151012/7b13f4cc/attachment.html>