Open Stack

Ian,

Overthinking and corner cases led to the existing implementation which
doesn't solve the MTU problem and arguably makes the situation worse
because options in the configuration files give operators the impression
they can control it. For example, the segment_mtu does nothing in the
in-tree drivers, the network_device_mtu option only impacts parts of some
in-tree drivers, and path_mtu only provides a way to change the MTU for VMs
for all in-tree drivers. I ran my experiments without any of these options
to provide a clean slate for empirically analyzing the problem and finding
a solution for the majority of operators.

Matt

On Mon, Jan 25, 2016 at 6:31 AM, Sean M. Collins <sean at coreitpro.com> wrote:

> On Mon, Jan 25, 2016 at 01:37:55AM EST, Kevin Benton wrote:
> > At a minimum I think we should pick a default in devstack and dump a
> > warning in neutron if operators don't specify it.
>
> Here's the DevStack change that implements this.
>
> https://review.openstack.org/#/c/267604/
>
> Again this just fixes it for DevStack. Deployers still need to set the
> MTUs by hand in their deployment tool of choice. I would hope that we
> can still move forward with some sort of automatic discovery - and also
> figure out a way to take it from 3 different config knobs down to like
> one master knob, for the sake of sanity.
>
> --
> Sean M. Collins
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160125/303dd418/attachment.html>