On 3/30/22 06:40, Xavier Simonart wrote:
Hi Dumitru
On Mon, Mar 21, 2022 at 12:02 PM Dumitru Ceara <[email protected]> wrote:
On 3/21/22 10:56, Xavier Simonart wrote:
- send gratuitous arp on localnet
- send gratuitous arp for nat ips in localnet
- dns lookup : 1 HV, 2 LS, 2 LSPs/LS -- ovn-northd -- dp-groups=yes
- send gratuitous arp for NAT rules on distributed router
- 2 HVs, 1 lport/HV, localport ports
Signed-off-by: Xavier Simonart <[email protected]>
---
Hi Xavier,
tests/ovn.at | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/tests/ovn.at b/tests/ovn.at
index 166b5f72e..cf027703f 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
[...]
@@ -10391,7 +10395,7 @@ test_dns6() {
}
AT_CAPTURE_FILE([ofctl_monitor0.log])
-as hv1 ovs-ofctl monitor br-int resume --detach --no-chdir \
+as hv1 ovs-ofctl -t 300 monitor br-int resume --detach --no-chdir \
--pidfile=ovs-ofctl0.pid 2> ofctl_monitor0.log
Is this really needed? We set OVS_CTL_TIMEOUT=30 in atlocal.in.
Thanks for looking into this.
Yes :-)
The issue here is that we start an ovs-ofctl monitor, then run a few times
(send packet / check monitor.log).
The test is quite long, and on slow systems (e.g. VM running s390
architecture on a x86_64 host), the 30 seconds are not enough for all
tests, and hence monitoring stops. Then we check (for 30 seconds) whether
monitor.log contains what we expect ...
300 seconds might be a little much... just depends on how slow the system
is... Requires at least one minute on my system...
Thanks for the clarification on this.
Acked-by: Mark Michelson
I think this should be committed as-is since it's fixing the flakiness
of the tests.
With regards to the DNS test in particular, my assumption is that the
long timeout is needed because the DNS queries are falling back to
system default behavior when OVN is not able to answer the queries
successfully. This can take a very long time since the system will wait
a certain amount of time for a response and may retry the query a
multiple times as well. If there were some way to temporarily override
default system behavior it may end up speeding up the test and
eliminating the need to set the timeout so large.
It's also possible I'm completely wrong in the above paragraph :)
Thanks
Xavier
Thanks,
Dumitru
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
