[ovs-dev] [PATCH v5] OVN: Add support for Transport Zones

[Lucas Alvares Gomes]

On Thu, Apr 18, 2019 at 11:34 AM Lucas Alvares Gomes
<lucasagomes at gmail.com> wrote:
>
> Hi,
>
> On Wed, Apr 17, 2019 at 6:04 PM Ben Pfaff <blp at ovn.org> wrote:
> >
> > On Wed, Apr 17, 2019 at 04:55:24PM +0100, lmartins at redhat.com wrote:
> > > From: Lucas Alvares Gomes <lucasagomes at gmail.com>
> > >
> > > 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