[ovs-dev] [ovn] branch-20.09 tests fail with OVS higher than 2.14.0

Dumitru Ceara dceara at redhat.com
Fri Jul 9 13:00:32 UTC 2021


On 7/8/21 6:34 PM, Vladislav Odintsov wrote:
> Hi,

Hi Vladislav,

> 
> I see constantly failing test while OVN branch-20.09 against OVS higher than 2.14.0 (2.14.1, 2.14.2, branch-2.14):
> ovn -- ensure one gw controller restart in HA doesn't bounce the master
> 
> ## ---------------- ##
> ## Tested programs. ##
> ## ---------------- ##
> ./testsuite.at:1: /builddir/build/BUILD/ovn-20.09.1/openvswitch-2.14.1/vswitchd/ovs-vswitchd --version
> ovs-vswitchd (Open vSwitch) 2.14.1
> ./testsuite.at:1: /builddir/build/BUILD/ovn-20.09.1/openvswitch-2.14.1/utilities/ovs-vsctl --version
> ovs-vsctl (Open vSwitch) 2.14.1
> DB Schema 8.2.0
> ## ------------------ ##
> ## Running the tests. ##
> ## ------------------ ##
> testsuite: starting at: Thu Jul  8 17:44:21 MSK 2021
> testsuite: ending at: Thu Jul  8 17:44:52 MSK 2021
> testsuite: test suite duration: 0h 0m 31s
> ## ------------- ##
> ## Test results. ##
> ## ------------- ##
> ERROR: 1 test was run,
> 1 failed unexpectedly.
> ## ------------------------ ##
> ## Summary of the failures. ##
> ## ------------------------ ##
> Failed tests:
> ovn 20.09.1 test suite test groups:
>  NUM: FILE-NAME:LINE     TEST-GROUP-NAME
>       KEYWORDS
>   91: ovn.at:12245       ovn -- ensure one gw controller restart in HA doesn't bounce the master
> ## ---------------------- ##
> ## Detailed failed tests. ##
> ## ---------------------- ##
> #                             -*- compilation -*-
> 91. ovn.at:12245: testing ovn -- ensure one gw controller restart in HA doesn't bounce the master ...
> creating ovn-sb database
> creating ovn-nb database
> starting ovn-northd
> starting backup ovn-northd
> adding simulator 'main'
> adding simulator 'gw1'
> adding simulator 'gw2'
> adding simulator 'hv1'
> ./ovn.at:12277: ovn_populate_arp__
> stdout:
> OK
> OK
> OK
> OK
> OK
> OK
> 194ab858-5fe5-448c-9600-f00a52a120e6
> 511c7f52-8f85-4193-872b-f87c23420dfd
> dc46bb8e-35f5-420c-8874-b493c843fd31
> Waiting until 1 rows in sb Chassis with name=gw2...
> ovn-macros.at:346: waiting until test $count = $(count_rows $db:$table $a $b $c)...
> ovn-macros.at:346: wait failed after 30 seconds
> sb table Chassis has the following rows. 0 rows match instead of expected 1:
> _uuid               : a74cd080-1302-4224-9590-462017d88783
> encaps              : [393b112b-329d-4db1-9926-cd06124a6f2b, df12c311-1563-4202-a197-02686d835867]
> external_ids        : {datapath-type="", iface-types="dummy,dummy-internal,dummy-pmd,erspan,geneve,gre,gtpu,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan", is-interconn="false", ovn-bridge-mappings="", ovn-chassis-mac-mappings="", ovn-cms-options="", ovn-enable-lflow-cache="true", ovn-monitor-all="false"}
> hostname            : bldrvm02
> name                : hv1
> nb_cfg              : 0
> other_config        : {datapath-type="", iface-types="dummy,dummy-internal,dummy-pmd,erspan,geneve,gre,gtpu,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan", is-interconn="false", ovn-bridge-mappings="", ovn-chassis-mac-mappings="", ovn-cms-options="", ovn-enable-lflow-cache="true", ovn-monitor-all="false"}
> transport_zones     : []
> vtep_logical_switches: []
> _uuid               : 780ad589-47d9-4658-b1fb-e0ec96f96ad0
> encaps              : [2bed8f4c-dc55-444d-a259-b12c04a63b62, 752086e4-6372-4840-9f92-fd4a8df3ba21]
> external_ids        : {datapath-type="", iface-types="dummy,dummy-internal,dummy-pmd,erspan,geneve,gre,gtpu,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan", is-interconn="false", ovn-bridge-mappings="phys:br-phys", ovn-chassis-mac-mappings="", ovn-cms-options="", ovn-enable-lflow-cache="true", ovn-monitor-all="false"}
> hostname            : bldrvm02
> name                : gw1
> nb_cfg              : 0
> other_config        : {datapath-type="", iface-types="dummy,dummy-internal,dummy-pmd,erspan,geneve,gre,gtpu,internal,ip6erspan,ip6gre,lisp,patch,stt,system,tap,vxlan", is-interconn="false", ovn-bridge-mappings="phys:br-phys", ovn-chassis-mac-mappings="", ovn-cms-options="", ovn-enable-lflow-cache="true", ovn-monitor-all="false"}
> transport_zones     : []
> vtep_logical_switches: []
> ./ovs-macros.at:222: hard failure
> 91. ovn.at:12245: 91. ovn -- ensure one gw controller restart in HA doesn't bounce the master (ovn.at:12245): FAILED (ovs-macros.at:222)
> 
> 
> I also tried to build OVN with OVS 2.15 and it doesn’t build at all because of renaming "slave" to "member" in OVS.
> 
> Some questions here:

I'm not a maintainer (maintainers in cc) but I'll try to answer some of
your questions.

> 
> 1. As I understand, changes in OVS branch brought regression in OVN. Shouldn't OVN periodically run github actions workflow for supported branches, not only for master branch? Against supported OVS branches and tags.

We run github actions and tests for supported branches, e.g.:

https://github.com/ovn-org/ovn/actions?query=branch%3Abranch-20.09

> 2. Is there any place where OVN versions are written against supported OVS versions, like OVS does for kernel versions and DPDK?

This is hard.  More recent branches contain OVS as a git submodule and
that is the version we run tests against in CI, that is, the version
known to be working fine at least for build requirements.

> 3. About the failing test: I found such fail was already observed in OVN (https://mail.openvswitch.org/pipermail/ovs-dev/2020-October/376362.html) and there was a fix in OVS, but now it reproduces again. I tried to apply patch http://patchwork.ozlabs.org/project/ovn/patch/1603185512-8070-1-git-send-email-dceara@redhat.com/ and it solved the problem. Now it looksk the only one OVS tag, with which branch-20.09 can be built - 2.14.0.

Maybe we should backport this to 20.09 then?

> 4. It is not clear which OVN versions are suppoted/LTS. Does OVN project have such decisions?

As far as I know, OVN mentions LTS in the documentation but until now,
since the OVS-OVN split there was no release tagged as LTS.

> 5. It is not also clear to understand the upgrade policy. Should administrator upgrade to each major OVN version or some versions can be skipped especially when since 20.12 release there is a version pinning between ovn-controller and ovn-northd? I couldn’t find answer for this question in OVN documentation.

Version pinning just ensures that there's no dataplane disruption when
upgrading between versions that change the DB schema.  I don't think
there's a limitation about upgrading to the next major OVN version
(unless there's a bug somewhere).

> 
> Sorry for a lot of questions, but there is some misunderstanding, which I need to resolve...
> 
> Regards,
> Vladislav Odintsov
> 

Regards,
Dumitru



More information about the dev mailing list