I've now verified the l3_agent works fine using a real quantum external network (external_network_bridge set to the empty string in config) with both openvswitch and linuxbridge using devstack. I'm working on a patch for devstack that will serve as the resolution for this bug.
My current plan is to configure this in devstack using the following localrc settings:
EXT_NETWORK_TYPE: external network's type (flat, vlan, local, ...)
EXT_PHYSICAL_NETWORK: external network's physical network name
EXT_SEGMENTATION_ID: external network's segmentation id (VLAN tag, tunnel ID, ...)
If EXT_NETWORK_TYPE is set, then PUBLIC_BRIDGE must not also be set, br-ex will not be configured, and the external network will be configured as a provider network with the specified attributes.
Comments?
Is it worth having devstack optionally setup the host as the external network's gatway?
I've now verified the l3_agent works fine using a real quantum external network (external_ network_ bridge set to the empty string in config) with both openvswitch and linuxbridge using devstack. I'm working on a patch for devstack that will serve as the resolution for this bug.
My current plan is to configure this in devstack using the following localrc settings:
EXT_NETWORK_TYPE: external network's type (flat, vlan, local, ...) NETWORK: external network's physical network name N_ID: external network's segmentation id (VLAN tag, tunnel ID, ...)
EXT_PHYSICAL_
EXT_SEGMENTATIO
If EXT_NETWORK_TYPE is set, then PUBLIC_BRIDGE must not also be set, br-ex will not be configured, and the external network will be configured as a provider network with the specified attributes.
Comments?
Is it worth having devstack optionally setup the host as the external network's gatway?