Re: [openstack-dev] [Neutron] Being more aggressive with our defaults

2016-02-10 Thread Carl Baldwin
On Mon, Feb 8, 2016 at 9:40 AM, Assaf Muller wrote: > As for DVR, I'm searching for someone to pick up the gauntlet and > contribute some L3 fullstack tests. I'd be more than happy to review > it! I even have an abandoned patch that gets the ball rolling (The > idea is to test

Re: [openstack-dev] [Neutron] Being more aggressive with our defaults

2016-02-10 Thread Miguel Angel Ajo Pelayo
> On 09 Feb 2016, at 21:43, Sean M. Collins wrote: > > Kevin Benton wrote: >> I agree with the mtu setting because there isn't much of a downside to >> enabling it. However, the others do have reasons to be disabled. >> >> csum - requires runtime detection of support for a

Re: [openstack-dev] [Neutron] Being more aggressive with our defaults

2016-02-09 Thread Kevin Benton
I agree with the mtu setting because there isn't much of a downside to enabling it. However, the others do have reasons to be disabled. csum - requires runtime detection of support for a feature and then auto degradation for systems that don't support it. People were against those so we have the

Re: [openstack-dev] [Neutron] Being more aggressive with our defaults

2016-02-09 Thread Omer Anson
Hi, > I'm generally sympathetic to what you're saying, and I agree that we > need to do something about disabled-by-default features, at the very > least on the testing front. Comments in-line. > > On Mon, Feb 8, 2016 at 4:47 PM, Sean M. Collins wrote: > > Hi, > > > > With the path_mtu

Re: [openstack-dev] [Neutron] Being more aggressive with our defaults

2016-02-08 Thread Monty Taylor
On 02/08/2016 09:47 AM, Sean M. Collins wrote: Hi, With the path_mtu issue - our default was to set path_mtu to zero, and do no calculation against the physical segment MTU and the overhead for the tunneling protocol that was selected for a tenant network. Which means the network would break.

[openstack-dev] [Neutron] Being more aggressive with our defaults

2016-02-08 Thread Sean M. Collins
Hi, With the path_mtu issue - our default was to set path_mtu to zero, and do no calculation against the physical segment MTU and the overhead for the tunneling protocol that was selected for a tenant network. Which means the network would break. I am working on patches to change our behavior to

Re: [openstack-dev] [Neutron] Being more aggressive with our defaults

2016-02-08 Thread Assaf Muller
I'm generally sympathetic to what you're saying, and I agree that we need to do something about disabled-by-default features, at the very least on the testing front. Comments in-line. On Mon, Feb 8, 2016 at 4:47 PM, Sean M. Collins wrote: > Hi, > > With the path_mtu issue -