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" <s...@coreitpro.com>To:"OpenStack Development
Mailing List (not for usage questions)"
<openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
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
