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.
Reviewed: https:/ /review. openstack. org/299205 /git.openstack. org/cgit/ openstack/ charm-neutron- gateway/ commit/ ?id=5dee017f12a d37838d5a3dfa78 4e60644edf4565
Committed: https:/
Submitter: Jenkins
Branch: master
commit 5dee017f12ad378 38d5a3dfa784e60 644edf4565
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 network_ bridge = (intentionally blank), external_ network_ id = (blank) and update the README with
networks when ext-port is not set. In this case we configure
external_
gateway_
information on using this new style of configuration.
The current template configures external networks by using the default network_ bridge= br-ex (implied when not set). This activates network_ type, provider: physical_ network and segmentation_ id are ignored. You cannot create multiple
external_
legacy code which assumes that a single external network exists on
that bridge and the L3 Agent directly plugs itself in.
provider:
provider:
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 physical_ network
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:
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, docs.openstack. org/liberty/ networking- guide/scenario- classic- ovs.html
see discussions in LP#1491668, LP#1525059 and
http://
Change-Id: I8d2bb8098e0809 69e0445293b1ed7 9714b2c964f
Related-Bug: #1491668
Related-Bug: #1525059
Closes-Bug: #1536768