On Thu, Apr 18, 2019 at 11:34 AM Lucas Alvares Gomes <[email protected]> wrote: > > Hi, > > On Wed, Apr 17, 2019 at 6:04 PM Ben Pfaff <[email protected]> wrote: > > > > On Wed, Apr 17, 2019 at 04:55:24PM +0100, [email protected] wrote: > > > From: Lucas Alvares Gomes <[email protected]> > > > > > > This patch is adding support for Transport Zones. Transport zones (a.k.a > > > TZs) is way to enable users of OVN to separate Chassis into different > > > logical groups that will only form tunnels between members of the same > > > groups. Each Chassis can belong to one or more Transport Zones. If > > > not set, the Chassis will be considered part of a default group. > > > > [...] > > > > > v4 -> v5 > > > * Bumped the version of the ovn-sb.ovsschema to 2.2.1. > > > > The version should become 2.3.0, see ovsdb.7: > > > > An OVSDB schema also has a version of the form ``x.y.z`` > > e.g. ``1.2.3``. Schemas managed within the Open vSwitch project > > manage version numbering in the following way (but OVSDB does not > > mandate this approach). Whenever we change the database schema in a > > non-backward compatible way (e.g. when we delete a column or a > > table), we increment <x> and set <y> and <z> to 0. When we change > > the database schema in a backward compatible way (e.g. when we add a > > new column), we increment <y> and set <z> to 0. When we change the > > database schema cosmetically (e.g. we reindent its syntax), we > > increment <z>. The ``ovsdb-tool`` commands ``schema-version`` and > > ``db-version`` extract the schema version from a schema or database > > file, respectively. > > > > Ops my bad, I will bump it to 2.3.0. Thanks for the pointer to the > documentation, it's very helpful. > > > But the main issue I see here is that I get a consistent test failure in > > the new test: > > > > # -*- compilation -*- > > 2693. ovn.at:13656: testing ovn -- test transport zones ... > > creating ovn-sb database > > creating ovn-nb database > > starting ovn-northd > > starting backup ovn-northd > > adding simulator 'main' > > adding simulator 'hv1' > > adding simulator 'hv2' > > adding simulator 'hv3' > > adding simulator 'hv4' > > adding simulator 'hv5' > > ../../tests/ovn.at:13669: ovs-vsctl --bare --columns=name find interface > > type="geneve" | awk NF | sort > > --- - 2019-04-17 10:02:31.402675315 -0700 > > +++ /home/blp/nicira/ovs/_build/tests/testsuite.dir/at-groups/2693/stdout > > 2019-04-17 10:02:31.397247995 -0700 > > @@ -1,5 +1,4 @@ > > ovn-hv2-0 > > ovn-hv3-0 > > ovn-hv4-0 > > -ovn-hv5-0 > > > > 2693. ovn.at:13656: 2693. ovn -- test transport zones (ovn.at:13656): > > FAILED (ovn.at:13669) > > Thanks for trying it out. > > I'm currently investigating the problem but I could not reproduce it > locally. I did run this test multiple times on different distros > (CentOS 7 [0], Fedora 29 [1] and Ubuntu Bionic [2]) and it's passing > for me. I'm doing the following: > > $ make check TESTSUITEFLAGS="--list --keywords=ovn" | grep "transport zones" > > Then I use the test number from the previous command and run the test as: > > $ make check TESTSUITEFLAGS="--verbose 2693" > > I will continue the investigation to see if can find the problem. > > Also, mind letting me know how you're executing the tests so I can try > it as well ? >
Update: I was able to reproduce the problem by stressing all CPUs in the background and running that test. I will work on a fix for the problem and upload a new version of the patch with the version and test fixed. Thanks Ben for finding the problem in the first place. [0] https://pastebin.com/zPrPVGd7 Cheers, Lucas _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
