This test started recently [1] to become flaky (since remote ports are
related ports).
Note that the test should in fact always fail (and not only randomly),
but due to some (independent) issues in CHECK_RELATED_PORTS_AFTER_RECOMPUTE
this is not always visible.
The CHECK_RELATED_PORTS_AFTER_RECOMPUTE macro issue will be
fixed separately.

[1] ba2db3b9a5d0 ("northd: Fix broadcast of all traffic within a transit spine 
switch.")

Fixes: ba2db3b9a5d0 ("northd: Fix broadcast of all traffic within a transit 
spine switch.")
Signed-off-by: Xavier Simonart <xsimo...@redhat.com>
---
 tests/ovn-ic.at | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/tests/ovn-ic.at b/tests/ovn-ic.at
index b848b37e8..0fd38acb2 100644
--- a/tests/ovn-ic.at
+++ b/tests/ovn-ic.at
@@ -1721,8 +1721,24 @@ for s_az in $(seq 1 $n_az); do
 done
 OVS_WAIT_UNTIL([check_packets], [$at_diff -F'^---' expected received])
 
+# ts[i] become local datapaths in hv[az] right before we lrp-set the
+# gateway-chassis on lrp-lr$az-$i-ts$i.
+# For ts1 & ts2, there are recomputes after the gateway-chassis has been set
+# (e.g. when some tunnel_keys get added), and hence they get removed from
+# local datapaths.
+# However this is not the case for ts3: there is no recompute, and local
+# datapaths are usually not removed in I+P. Ignore this.
+# Also, ts3 remaining a local datapath, and lsp-ts3-lr[x]-3 being remote port, 
it
+# is a related port. Ignore this also
+ovn_as az1 OVN_CLEANUP_SBOX([hv1], [], ["lsp-ts3-lr2-3
+lsp-ts3-lr3-3"], [ts3])
+ovn_as az2 OVN_CLEANUP_SBOX([hv2], [], ["lsp-ts3-lr1-3
+lsp-ts3-lr3-3"], [ts3])
+ovn_as az3 OVN_CLEANUP_SBOX([hv3], [], ["lsp-ts3-lr1-3
+lsp-ts3-lr2-3"], [ts3])
+
 for az in `seq 1 $n_az`; do
-    OVN_CLEANUP_SBOX([hv$az])
+    ovn_as az$az
     OVN_CLEANUP_SBOX([gw$az])
     OVN_CLEANUP_AZ([az$az])
 done
-- 
2.47.1

_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to