Open Stack

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 <sean at coreitpro.com> 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.
>
> I am working on patches to change our behavior to set the MTU to 1500 by
> default[1], so that at least our out of the box experience is more
> sensible.
>
> This brings me to the csum feature of recent linux kernel versions and
> related network components.
>
> Patches:
>
> https://review.openstack.org/#/c/220744/
> https://review.openstack.org/#/c/261409/
>
> Bugs/RFEs:
>
> https://bugs.launchpad.net/neutron/+bug/1515069
> https://bugs.launchpad.net/neutron/+bug/1492111
>
> Basically, we see that enabling the csum feature creates the conditions
> where 10gig link were able to be fully utilized[2] in one instance[3]. My
> thinking is - yes I too would like to fully utilize the links that I
> paid good money for. Someone with more knowledge can correct me
> , but is there any reason not to enable this feature? If your hardware
> supports it, we should utilize it. If your hardware doesn't support it,
> then we shouldn't.
>
> tl;dr - why do we keep merging features that create more knobs that
> deployers and deployment tools need to keep turning? The fact that we
> merge features that are disabled by default means that they are not as
> thoroughly tested as features that are enabled by default.

That is partially a testing issue which fullstack is supposed to
solve. We can't afford to set up a job for every combination of
Neutron configuration values, not upstream and not in different
downstream CI environments. Fullstack can test different
configurations knobs quickly, and it's something that a developer can
do on his own without depending on infra changes. It's also easy to
run, and thus easy to iterate.

As for concrete actions, we do have a fullstack test that enables
l2pop and checks connectivity between two VMs on different nodes. It's
the only code patch that actually covers l2pop at the upstream gate!
It already caught a regression that Armando and I fixed a while ago.
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 L3 east/west, north/south with FIP and north/south
without FIP for all four router types: Legacy, HA, DVR and DVR HA. You
run the same test in four different configurations, fullstack is
basically purpose built for this).

>
> Neutron should have a lot of things enabled by default that improve
> performance (l2pop? path_mtu? dvr?), and by itself, try and enable these
> features. If for some reason the hardware doesn't support it, log that
> it wasn't successful and then disable.

I don't know if this is what you wanted to talk about (It feels more
like a side note to me, so I'm sorry if I'm about to hijack the
conversation!), but I think that if an admin sets a certain
configuration option, the software should respect it in a predictable
manner. If an agent tries to use a certain config knob and fails, it
should error out (Saying specifically what's wrong), and not disable
the option but keep on living, because that is surprising behavior,
and there's nothing telling the admin that the option he expects to be
on is actually off, until he notices it the hard way some time later.

>
> OK - that's it for me. Thanks for reading. I'll put on my asbestos
> undies now.
>
>
> [1]: https://review.openstack.org/#/c/276411/
> [2]: http://openvswitch.org/pipermail/dev/2015-August/059335.html
>
> [3]: Yes, it's only one data point....
>
> --
> 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