{"push_id":1197918808,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"23bd2cee08b94a2448504d6c17a660e8fb2f7b0a","before":"e8dd13a55f74b74b028db6a65381d3bdc690af3c","commits":[{"sha":"23bd2cee08b94a2448504d6c17a660e8fb2f7b0a","author":{"name":"Jenkins","email":"61eb39d4445155efb6068840385577c11776cd20@review.openstack.org"},"message":"Updated openstack/openstack\nProject: openstack/tripleo-heat-templates  0dd151201f86688ce8cf1773ccacf69932a996c1\n\nneutron: remove tenant MTU configuration options\n\nSince Mitaka, Neutron and Nova do the right thing for MTU, correctly\ncalculating and applying MTU per network, considering its network type\nand underlying physical network MTU (1500 by default). Neutron now also\ncorrectly advertise proper MTU to instances through DHCP and RA\nmechanisms. With that, there is no reason to have those MTU hacks in\ndeployment tools. Actually, they not only do no good, but break some\nsetups (Jumbo frame aware infrastructure), or at least make them\nnon-optimal (lowering instance MTU to 1400 when it's not needed, or when\ntunnel overhead does not require 100 bytes).\n\nNote that Neutron still has a set of configuration options to allow for\ncustom physical network MTUs (global_physnet_mtu, path_mtu,\nphysical_network_mtus). Those options define underlying infrastructure\nthough, not tenant MTUs. To support Jumbo frames, TripleO should allow\nto set those options. That said, it's not the immediate goal of the\npatch, and hence such an effort would require a separate patch.\n\nMitaka+ documentation on MTU configuration for Neutron:\nhttp://docs.openstack.org/mitaka/networking-guide/adv-config-mtu.html\n\nChange-Id: I540ba5dc69d0506f71b59746efcce94c73f9317f","distinct":true,"url":"https://api.github.com/repos/openstack/openstack/commits/23bd2cee08b94a2448504d6c17a660e8fb2f7b0a"}]}
{"actor":{"display_login":"openstack-gerrit"}}