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

README.md

@@ -178,3 +178,65 @@ By default, the charm will configure Open vSwitch/DPDK to consume a processor co
 **NOTE:** Enabling DPDK support automatically disables security groups for instances.
 
 [dpdk-nics]: http://dpdk.org/doc/nics
+
+# Port Configuration
+
+**NOTE:** External port configuration only applies when DVR mode is enabled.
+
+All network types (internal, external) are configured with bridge-mappings and
+data-port and the flat-network-providers configuration option of the
+neutron-api charm.  Once deployed, you can configure the network specifics
+using neutron net-create.
+
+If the device name is not consistent between hosts, you can specify the same
+bridge multiple times with MAC addresses instead of interface names.  The charm
+will loop through the list and configure the first matching interface.
+
+Basic configuration of a single external network, typically used as floating IP
+addresses combined with a GRE private network:
+
+    neutron-openvswitch:
+        bridge-mappings:         physnet1:br-ex
+        data-port:               br-ex:eth1
+    neutron-api:
+        flat-network-providers:  physnet1
+
+    neutron net-create --provider:network_type flat \
+        --provider:physical_network physnet1 --router:external=true \
+        external
+    neutron router-gateway-set provider external
+
+Alternative configuration with two networks, where the internal private
+network is directly connected to the gateway with public IP addresses but a
+floating IP address range is also offered.
+
+    neutron-openvswitch:
+        bridge-mappings:         physnet1:br-data external:br-ex
+        data-port:               br-data:eth1 br-ex:eth2
+    neutron-api:
+        flat-network-providers:  physnet1 external
+
+Alternative configuration with two external networks, one for public instance
+addresses and one for floating IP addresses.  Both networks are on the same
+physical network connection (but they might be on different VLANs, that is
+configured later using neutron net-create).
+
+    neutron-openvswitch:
+        bridge-mappings:         physnet1:br-data
+        data-port:               br-data:eth1
+    neutron-api:
+        flat-network-providers:  physnet1
+
+    neutron net-create --provider:network_type vlan \
+        --provider:segmentation_id 400 \
+        --provider:physical_network physnet1 --shared external
+    neutron net-create --provider:network_type vlan \
+        --provider:segmentation_id 401 \
+        --provider:physical_network physnet1 --shared --router:external=true \
+        floating
+    neutron router-gateway-set provider floating
+
+This replaces the previous system of using ext-port, which always created a bridge
+called br-ex for external networks which was used implicitly by external router
+interfaces.
+

config.yaml

@@ -99,6 +99,10 @@ options:
     type: string
     default:
     description: |
+      Deprecated: Use bridge-mappings and data-port to create a network
+      which can be used for external connectivity.  You can call the network
+      external and the bridge br-ex by convention, but neither is required
+
       A space-separated list of external ports to use for routing of instance
       traffic to the external public network. Valid values are either MAC
       addresses (in which case only MAC addresses for interfaces without an IP

hooks/neutron_ovs_context.py

@@ -107,8 +107,11 @@ class L3AgentContext(OSContextGenerator):
         ctxt = {}
         if neutron_api_settings['enable_dvr']:
             ctxt['agent_mode'] = 'dvr'
+            if not config('ext-port'):
+                ctxt['external_configuration_new'] = True
         else:
             ctxt['agent_mode'] = 'legacy'
+
         return ctxt
 
 

templates/juno/l3_agent.ini

@@ -5,3 +5,7 @@
 [DEFAULT]
 interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
 agent_mode = {{ agent_mode }}
+{% if external_configuration_new -%}
+gateway_external_network_id =
+external_network_bridge =
+{% endif %}

unit_tests/test_neutron_ovs_context.py

@@ -244,7 +244,10 @@ class L3AgentContextTest(CharmTestCase):
             'network-device-mtu': 1500,
         }
         _rget.side_effect = lambda *args, **kwargs: rdata
-        self.assertEquals(context.L3AgentContext()(), {'agent_mode': 'dvr'})
+        self.assertEquals(
+            context.L3AgentContext()(), {'agent_mode': 'dvr',
+                                         'external_configuration_new': True}
+        )
 
     @patch.object(charmhelpers.contrib.openstack.context, 'relation_get')
     @patch.object(charmhelpers.contrib.openstack.context, 'relation_ids')