[openstack-dev] [DevStack] Adding PUBLIC_INTERFACE to OVS_PHYSICAL_BRIDGE by default

Kyle Mestery mestery at mestery.com
Fri Feb 27 15:38:46 UTC 2015


On Thu, Feb 26, 2015 at 9:12 AM, Sean M. Collins <sean at coreitpro.com> wrote:

> Hi,
>
> I have proposed a recent patch, that when using Neutron as the
> networking component in DevStack, the PUBLIC_INTERFACE that has been set
> should automatically be added to the OVS_PHYSICAL_BRIDGE.
>
> https://review.openstack.org/#/c/158424/
>
> Thanks for taking this work on Sean!


> There are a couple motivations for this patch. The first is that in my
> Vagrant project, I've been using chef[0] to attach the public interface
> to the OVS bridge, so that when a floating IP is NAT'd traffic flows
> from the interface attached to the router where the floating IP range is
> advertised, into the L3 agent.
>
> This is basically the same step documented for setting up a production
> Neutron install[1]. The fact that we are not doing this for DevStack
> installations is an oversight that should be corrected.
>
> The second motivation for this patch is to help transition DevStack
> users from Nova-Networking. Recently, we tried to move Neutron to being
> the default, but the lack of code to configure DevStack on machines with
> a single network interface caused a lot of issues and had to be
> reverted.
>
> In cases where DevStack is being run on a developer machine, where only
> one physical interface is present, DevStack will remove the IP address
> that has been assigned to the machine and adds it to the
> OVS_PHSYICAL_BRIDGE, so that the machine as well as the OpenStack APIs
> are reachable, while also allowing the usage of floating IPs.
>

This all sounds good to me. I'll review the patch in more detail and
provide specific comments there.


> An example local.conf shows how this is configured. On this machine, we
> have a router that advertises the 192.168.27.0/24 prefix. The DevStack
> machine will be assigned 192.168.27.2 from DHCP, and the remaining IPs
> in the /24 will be used for floating IP addresses.
>
>         HOST_IP=192.168.27.2
>         FLAT_INTERFACE=eth0
>         PUBLIC_INTERFACE=eth0
>         FIXED_RANGE=10.0.0.0/24
>         FLOATING_RANGE=192.168.27.0/24
>         PUBLIC_NETWORK_GATEWAY=192.168.27.1
>
>         disable_service n-net
>         enable_service q-svc
>         enable_service q-agt
>         enable_service q-dhcp
>         enable_service q-meta
>         enable_service q-l3
>
>         Q_USE_SECGROUP=True
>         ENABLE_TENANT_VLANS=True
>         TENANT_VLAN_RANGE=3001:4000
>         OVS_PHYSICAL_BRIDGE=br-ex
>         Q_L3_ENABLED=True
>         Q_FLOATING_ALLOCATION_POOL=start=192.168.27.3,end=192.168.27.254
>
> I'd be interested in feedback from everyone about my thought process,
> code, and if I'm on the right track.
>
> [0]:
> https://github.com/sc68cal/chef-devstack/blob/master/recipes/default.rb#L50
> [1]:
> http://docs.openstack.org/admin-guide-cloud/content/install_neutron-l3.html
> [2]: https://review.openstack.org/#/c/153208/
>
> --
> 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/20150227/9d206b0d/attachment.html>


More information about the OpenStack-dev mailing list