Neutron-gateway charm support for multiple external networks on a single l3 agent

[Robert Baker]

This is more of a feature enhancement request than a bug. If this isn't the appropriate forum for enhancement requests please point me in the proper direction.

When setting up a liberty openstack with MAAS/Juju I utilized the neutron-gateway charm. When the time came to add a second external network to the configuration I needed to alter the neutron-gateway charm l3_agent.ini template to seed the appropriate values for my desired configuration.

My goal was to setup multiple external nets like this document:
http://blog.oddbit.com/2014/05/28/multiple-external-networks-wit/

But the charm did not appear to support setting these two values to blank:
external_network_bridge =
gateway_external_network_id =

I was able to work around this issue for my own purposes by editing the template to unconditionally insert those two lines, but I'm sure my solution isn't the appropriate solution for every configuration.

Thank you

[Robert Baker (robertb-5)]

Just in case anyone else would like to use my temporary hack method to get more than one ext-net running on a single l3 agent here is a patch for unconditionally inserting the two values referenced above.

As I said before, I am sure this isn't appropriate for every implementation, but it is how I worked around my issue.

In order to use this successfully it will need to be teamed up with appropriate bridge/port mappings as described in the document I linked in my last port.

[Florian Haas (fghaas)]

GIven the fact that the "one L3 agent per external network" method has been obsolete for a while, I'd say at this point this definitely is a bug. The multiple flat external networks approach described in the linked blog post has been available for two full years.

There is an additional problem here: suppose you have two network gateway nodes. Normally you would use those to deploy HA routers. If you want to support two external networks, what Juju currently forces you to do is deploy two neutron-gateway services, each connected to a different external network — which means you can never run HA routers, at least not if they are meant to be connected to external networks.

This charm really *must* support an empty external_network_bridge and gateway_external_network_id.

[James Page (james-page)]

On-hold review for 16.07:

https://review.openstack.org/#/c/299205

[James Page (james-page)]

Raising n-ovs task to support this type of external networking in DVR mode as well.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/329582

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/299205
Committed: https://git.openstack.org/cgit/openstack/charm-neutron-gateway/commit/?id=5dee017f12ad37838d5a3dfa784e60644edf4565
Submitter: Jenkins
Branch: master

commit 5dee017f12ad37838d5a3dfa784e60644edf4565
Author: Trent Lloyd <email address hidden>
Date: Wed Mar 23 00:33:06 2016 +0800

    Support new style (and multiple) external networks

    Switch the generated configuration to use "new" style external
    networks when ext-port is not set. In this case we configure
    external_network_bridge = (intentionally blank),
    gateway_external_network_id = (blank) and update the README with
    information on using this new style of configuration.

    The current template configures external networks by using the default
    external_network_bridge=br-ex (implied when not set). This activates
    legacy code which assumes that a single external network exists on
    that bridge and the L3 Agent directly plugs itself in.
    provider:network_type, provider:physical_network and
    provider:segmentation_id are ignored. You cannot create multiple
    networks and you cannot use segmented networks (e.g. VLAN)

    By setting external_network_bridge = (intentionally blank) the L2
    Agent handles the configuration instead, this allows us to create
    multiple networks and also to use more complex network configurations
    such as VLAN. It is also possible to use the same physical connection
    with different segmentation IDs for both internal and external
    networks, as well as multiple external networks.

    Legacy/existing configurations where ext-port is set generate the same
    configuration as previous and should continue to work as before. I do
    not believe it to be easy to migrate existing setups to the "new"
    style configuration automatically as changes to the neutron network
    configuration may be required (specifically: provider:physical_network
    will now be used when it was not before, and may not be correct) and
    the physical port needs to be moved from br-ex to br-data which the
    charm does not currently handle and is likely to error as it does not
    attempt removal first. Further work may be possible in this area.

    For information about this new style of configuration being preferred,
    see discussions in LP#1491668, LP#1525059 and
    http://docs.openstack.org/liberty/networking-guide/scenario-classic-ovs.html

    Change-Id: I8d2bb8098e080969e0445293b1ed79714b2c964f
    Related-Bug: #1491668
    Related-Bug: #1525059
    Closes-Bug: #1536768

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/329582
Committed: https://git.openstack.org/cgit/openstack/charm-neutron-openvswitch/commit/?id=85cf60219b3bdf92fca1bdfc19bb41b3dba0bd3a
Submitter: Jenkins
Branch: master

commit 85cf60219b3bdf92fca1bdfc19bb41b3dba0bd3a
Author: James Page <email address hidden>
Date: Tue Jun 14 18:09:52 2016 +0100

    Support new style (and multiple) external networks

    Note that this change only impacts use of this charm when
    Distributed Virtual Routing is enabled in a deployment.

    Switch the generated configuration to use "new" style external
    networks when ext-port is not set. In this case we configure:

      external_network_bridge = (intentionally blank)
      gateway_external_network_id = (blank)

    The current template configures external networks by using the default
    external_network_bridge=br-ex (implied when not set). This activates
    legacy code which assumes that a single external network exists on
    that bridge and the L3 Agent directly plugs itself in.
    provider:network_type, provider:physical_network and
    provider:segmentation_id are ignored. You cannot create multiple
    networks and you cannot use segmented networks (e.g. VLAN)

    By setting external_network_bridge = (intentionally blank) the L2
    Agent handles the configuration instead, this allows us to create
    multiple networks and also to use more complex network configurations
    such as VLAN. It is also possible to use the same physical connection
    with different segmentation IDs for both internal and external
    networks, as well as multiple external networks.

    Legacy/existing configurations where ext-port is set generate the same
    configuration as previous and should continue to work as before.
    Migration from legacy to new style configuration is not supported.

    Change-Id: I3d06581850ccbe5ea77741c4a546e663b2957a91
    Closes-Bug: #1536768