Open Stack

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 <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).

>

I am adding something similar to Dragonflow. It creates tap devices that mimic VMs connected via interfaces to the switch. This gives us complete control inside the tests to send and received a predefined set of packets though simple python code written inside the test.


I have successfully written an ARP responder test, and other tests (such as DHCP server testing, ping echo/reply tests, and the such) are in the works.


Currently, this set-up is geared towards a single compute-node testing. It can be easily extended further, to multi-node tests, incl. east-west communication, and north-south communication with and without FIP. It can also be used to verify that all the flags on the packet are set correctly.


Currently, these tests are in review in Dragonflow[4], but all of the heavy lifting is done either done via the Neutron API, or directly with the OVS switch. We could easily integrate it with neutron tests.


[4] https://review.openstack.org/275714


> > 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

-------------------------------------------------------------------------------------------------------------------------------------------------
This email and any files transmitted and/or attachments with it are confidential and proprietary information of
Toga Networks Ltd., and intended solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager. This message contains confidential
information of Toga Networks Ltd., and is intended only for the individual named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately
by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not
the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on
the contents of this information is strictly prohibited.
------------------------------------------------------------------------------------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160209/f92db8c1/attachment.html>