<HTML><head><style>pre {display: block;font-family: Helvetica Neue, Helvetica, Arial, sans-serif;white-space: pre-wrap;margin: 1em 0;}</style></head><BODY><PRE>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
</PRE><BR>
</BODY></HTML><br><br><div class="domino-section"><div class="domino-section-head"><span class="domino-section-title"><font color="#424282">Sean M. Collins --- Re: [openstack-dev] [devstack] [neutron] A larger batch of questions about configuring DevStack to use Neutron --- </font></span></div><div class="domino-section-body"><br><table width="100%" border="0" cellspacing="0" cellpadding="0"><tr valign="top"><td width="1%" style="width: 96px;"><font size="2" color="#5F5F5F">From:</font></td><td width="100%" style="width: auto;"><font size="2">"Sean M. Collins" <sean@coreitpro.com></font></td></tr><tr valign="top"><td width="1%" style="width: 96px;"><font size="2" color="#5F5F5F">To:</font></td><td width="100%" style="width: auto;"><font size="2">"OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org></font></td></tr><tr valign="top"><td width="1%" style="width: 96px;"><font size="2" color="#5F5F5F">Date:</font></td><td width="100%" style="width: auto;"><font size="2">Mon, Oct 12, 2015 11:34</font></td></tr><tr valign="top"><td width="1%" style="width: 96px;"><font size="2" color="#5F5F5F">Subject:</font></td><td width="100%" style="width: auto;"><font size="2">Re: [openstack-dev] [devstack] [neutron] A larger batch of questions about configuring DevStack to use Neutron</font></td></tr></table><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev