[ovs-dev] OVN testsuite failure on Travis
Ben Pfaff
blp at ovn.org
Sun May 8 16:31:18 UTC 2016
On Fri, May 06, 2016 at 01:28:49PM -0700, Joe Stringer wrote:
> Is the below testsuite failure on anyone's radar? It seems to be
> failing maybe 30% of the time on Travis. Travis is known to run the
> tests on heavily loaded systems and as such is likely to randomly
> reorder thread execution which increases the likelihood of race
> conditions causing testsuite failures; perhaps this could be
> reproduced locally by running significantly more tests at a time than
> you have cores.
>
> 2027: ovn.at:2203 ovn -- 1 HVs, 2 LSs, 1 lport/LS, 1 LR
>
> https://travis-ci.org/openvswitch/ovs/jobs/128351921#L7594
>
> The test output is like this:
>
> ../../tests/ovn.at:2321: cat received.packets
> --- expout 2016-05-05 00:00:35.843273515 +0000
> +++ /home/travis/build/openvswitch/ovs/openvswitch-2.5.90/_build/tests/testsuite.dir/at-groups/2027/stdout
> 2016-05-05 00:00:35.843273515 +0000
> @@ -1 +1,2 @@
> f0000001020400000001020408004500001c000000003f110100c0a80102ac100102003511110008
> +f0000001020400000001020408004500001c000000003f110100c0a80102ac100102003511110008
>
> Seems like we receive one more copy of the packet than the test
> expects. Is there a way we could use OVS_WAIT_UNTIL or something to
> address this race?
The most common races I see in the OVN tests would be addressed by the
idea I proposed here:
http://openvswitch.org/pipermail/dev/2016-April/070041.html
(please see the remainder of the thread for refinements)
I think that Ryan Moats (CCed) is planning to work on that.
However, it's not obvious to me how a lack of flows would cause *extra*
packets, so there might be another issue here too.
More information about the dev
mailing list