aboutsummaryrefslogtreecommitdiffstats
path: root/puppet/compute.yaml
diff options
context:
space:
mode:
authorIhar Hrachyshka <ihrachys@redhat.com>2016-06-06 15:36:54 +0200
committerBrent Eagles <beagles@redhat.com>2016-07-05 10:35:22 -0230
commit2a64b67cef74fff86ce6b56b15431b859515844d (patch)
tree5f4a8778ac31c5d6fa9e9177f601ddd54daa414f /puppet/compute.yaml
parent56398e72be4fe69add9b6e57a9b7d9ede6ece94c (diff)
neutron: remove tenant MTU configuration options
Since Mitaka, Neutron and Nova do the right thing for MTU, correctly calculating and applying MTU per network, considering its network type and underlying physical network MTU (1500 by default). Neutron now also correctly advertise proper MTU to instances through DHCP and RA mechanisms. With that, there is no reason to have those MTU hacks in deployment tools. Actually, they not only do no good, but break some setups (Jumbo frame aware infrastructure), or at least make them non-optimal (lowering instance MTU to 1400 when it's not needed, or when tunnel overhead does not require 100 bytes). Note that Neutron still has a set of configuration options to allow for custom physical network MTUs (global_physnet_mtu, path_mtu, physical_network_mtus). Those options define underlying infrastructure though, not tenant MTUs. To support Jumbo frames, TripleO should allow to set those options. That said, it's not the immediate goal of the patch, and hence such an effort would require a separate patch. Mitaka+ documentation on MTU configuration for Neutron: http://docs.openstack.org/mitaka/networking-guide/adv-config-mtu.html Change-Id: I540ba5dc69d0506f71b59746efcce94c73f9317f
Diffstat (limited to 'puppet/compute.yaml')
-rw-r--r--puppet/compute.yaml12
1 files changed, 0 insertions, 12 deletions
diff --git a/puppet/compute.yaml b/puppet/compute.yaml
index db2d7465..820a2acd 100644
--- a/puppet/compute.yaml
+++ b/puppet/compute.yaml
@@ -118,15 +118,6 @@ parameters:
default: nic1
description: A port to add to the NeutronPhysicalBridge.
type: string
- NeutronTenantMtu:
- description: >
- The default MTU for tenant networks. For VXLAN/GRE tunneling, this should
- be at least 50 bytes smaller than the MTU on the physical network. This
- value will be used to set the MTU on the virtual Ethernet device.
- This number is related to the value of NeutronDnsmasqOptions, since that
- will determine the MTU that is assigned to the VM host through DHCP.
- default: 1400
- type: number
NeutronTunnelTypes:
type: comma_delimited_list
description: |
@@ -517,7 +508,6 @@ resources:
nova::migration::live_migration_tunnelled: {get_input: nova_enable_rbd_backend}
rbd_persistent_storage: {get_input: cinder_enable_rbd_backend}
nova_password: {get_input: nova_password}
- nova::compute::network_device_mtu: {get_input: neutron_tenant_mtu}
nova::compute::vncserver_proxyclient_address: {get_input: nova_vnc_proxyclient_address}
nova::vncproxy::common::vncproxy_protocol: {get_input: nova_vncproxy_protocol}
nova::vncproxy::common::vncproxy_host: {get_input: nova_vncproxy_host}
@@ -543,7 +533,6 @@ resources:
neutron_host: {get_input: neutron_host}
neutron::agents::ml2::ovs::local_ip: {get_input: neutron_local_ip}
- neutron::network_device_mtu: {get_input: neutron_tenant_mtu}
neutron::plugins::ml2::tenant_network_types: {get_input: neutron_tenant_network_types}
neutron::agents::ml2::ovs::tunnel_types: {get_input: neutron_tunnel_types}
neutron::agents::ml2::ovs::extensions: {get_input: neutron_agent_extensions}
@@ -643,7 +632,6 @@ resources:
template: MAPPINGS
params:
MAPPINGS: {get_param: NeutronBridgeMappings}
- neutron_tenant_mtu: {get_param: NeutronTenantMtu}
neutron_enable_tunneling: {get_param: NeutronEnableTunnelling}
neutron_enable_l2pop: {get_param: NeutronEnableL2Pop}
neutron_physical_bridge: {get_param: NeutronPhysicalBridge}