From patchwork Thu May 5 01:01:05 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joe Stringer X-Patchwork-Id: 618742 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from archives.nicira.com (archives.nicira.com [96.126.127.54]) by ozlabs.org (Postfix) with ESMTP id 3r0c7j5Dpqz9sf6 for ; Thu, 5 May 2016 11:02:09 +1000 (AEST) Received: from archives.nicira.com (localhost [127.0.0.1]) by archives.nicira.com (Postfix) with ESMTP id 6EA46108CE; Wed, 4 May 2016 18:01:50 -0700 (PDT) X-Original-To: dev@openvswitch.org Delivered-To: dev@openvswitch.org Received: from mx1e4.cudamail.com (mx1.cudamail.com [69.90.118.67]) by archives.nicira.com (Postfix) with ESMTPS id 442A3108BE for ; Wed, 4 May 2016 18:01:47 -0700 (PDT) Received: from bar5.cudamail.com (unknown [192.168.21.12]) by mx1e4.cudamail.com (Postfix) with ESMTPS id C5D741E03D8 for ; Wed, 4 May 2016 19:01:46 -0600 (MDT) X-ASG-Debug-ID: 1462410106-09eadd60413bdcb0001-byXFYA Received: from mx1-pf1.cudamail.com ([192.168.24.1]) by bar5.cudamail.com with ESMTP id SBypqXnACPZDixBz (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 04 May 2016 19:01:46 -0600 (MDT) X-Barracuda-Envelope-From: joe@ovn.org X-Barracuda-RBL-Trusted-Forwarder: 192.168.24.1 Received: from unknown (HELO relay6-d.mail.gandi.net) (217.70.183.198) by mx1-pf1.cudamail.com with ESMTPS (DHE-RSA-AES256-SHA encrypted); 5 May 2016 01:01:45 -0000 Received-SPF: pass (mx1-pf1.cudamail.com: SPF record at ovn.org designates 217.70.183.198 as permitted sender) X-Barracuda-Apparent-Source-IP: 217.70.183.198 X-Barracuda-RBL-IP: 217.70.183.198 Received: from mfilter24-d.gandi.net (mfilter24-d.gandi.net [217.70.178.152]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id AF02DFB89F; Thu, 5 May 2016 03:01:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter24-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter24-d.gandi.net (mfilter24-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Rauf782hmAC7; Thu, 5 May 2016 03:01:43 +0200 (CEST) X-Originating-IP: 208.91.1.34 Received: from localhost.localdomain (unknown [208.91.1.34]) (Authenticated sender: joe@ovn.org) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id DBC98FB8AC; Thu, 5 May 2016 03:01:41 +0200 (CEST) X-CudaMail-Envelope-Sender: joe@ovn.org From: Joe Stringer To: dev@openvswitch.org X-CudaMail-Whitelist-To: dev@openvswitch.org X-CudaMail-MID: CM-E1-503098200 X-CudaMail-DTE: 050416 X-CudaMail-Originating-IP: 217.70.183.198 Date: Wed, 4 May 2016 18:01:05 -0700 X-ASG-Orig-Subj: [##CM-E1-503098200##][PATCH 3/4] system-traffic: Wait for IPv6 connectivity. Message-Id: <1462410066-41547-4-git-send-email-joe@ovn.org> X-Mailer: git-send-email 2.1.4 In-Reply-To: <1462410066-41547-1-git-send-email-joe@ovn.org> References: <1462410066-41547-1-git-send-email-joe@ovn.org> X-Barracuda-Connect: UNKNOWN[192.168.24.1] X-Barracuda-Start-Time: 1462410106 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://web.cudamail.com:443/cgi-mod/mark.cgi X-ASG-Whitelist: Header =?UTF-8?B?eFwtY3VkYW1haWxcLXdoaXRlbGlzdFwtdG8=?= X-Virus-Scanned: by bsmtpd at cudamail.com X-Barracuda-BRTS-Status: 1 Subject: [ovs-dev] [PATCH 3/4] system-traffic: Wait for IPv6 connectivity. X-BeenThere: dev@openvswitch.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: dev-bounces@openvswitch.org Sender: "dev" Several of the tests have race conditions where the next step in the test may run before the kernel actually provides IPv6 connectivity. This causes intermittent testsuite failures. Some existing tests would even sleep in an attempt to mitigate this issue. Improve the resilience of these tests by waiting until IPv6 or FTP connectivity are ready. This speeds the testsuite up by a couple of percent. Signed-off-by: Joe Stringer Acked-by: Jarno Rajahalme --- tests/system-traffic.at | 50 +++++++++++++++++++++++++++++++++---------------- 1 file changed, 34 insertions(+), 16 deletions(-) diff --git a/tests/system-traffic.at b/tests/system-traffic.at index a5ec11775a7b..9a1769fdb1af 100644 --- a/tests/system-traffic.at +++ b/tests/system-traffic.at @@ -79,9 +79,10 @@ ADD_NAMESPACES(at_ns0, at_ns1) ADD_VETH(p0, at_ns0, br0, "fc00::1/96") ADD_VETH(p1, at_ns1, br0, "fc00::2/96") -dnl Without this sleep, we get occasional failures due to the following error: +dnl Linux seems to take a little time to get its IPv6 stack in order. Without +dnl waiting, we get occasional failures due to the following error: dnl "connect: Cannot assign requested address" -sleep 2; +OVS_WAIT_UNTIL([ip netns exec at_ns0 ping6 -c 1 fc00::2]) NS_CHECK_EXEC([at_ns0], [ping6 -q -c 3 -i 0.3 -w 2 fc00::2 | FORMAT_PING], [0], [dnl 3 packets transmitted, 3 received, 0% packet loss, time 0ms @@ -109,9 +110,10 @@ ADD_VETH(p1, at_ns1, br0, "fc00::2/96") ADD_VLAN(p0, at_ns0, 100, "fc00:1::1/96") ADD_VLAN(p1, at_ns1, 100, "fc00:1::2/96") -dnl Without this sleep, we get occasional failures due to the following error: +dnl Linux seems to take a little time to get its IPv6 stack in order. Without +dnl waiting, we get occasional failures due to the following error: dnl "connect: Cannot assign requested address" -sleep 2; +OVS_WAIT_UNTIL([ip netns exec at_ns0 ping6 -c 1 fc00::2]) NS_CHECK_EXEC([at_ns0], [ping6 -q -c 3 -i 0.3 -w 2 fc00:1::2 | FORMAT_PING], [0], [dnl 3 packets transmitted, 3 received, 0% packet loss, time 0ms @@ -351,9 +353,10 @@ priority=100,in_port=2,ct_state=+trk+est,tcp6,action=1 AT_CHECK([ovs-ofctl --bundle add-flows br0 flows.txt]) -dnl Without this sleep, we get occasional failures due to the following error: +dnl Linux seems to take a little time to get its IPv6 stack in order. Without +dnl waiting, we get occasional failures due to the following error: dnl "connect: Cannot assign requested address" -sleep 2; +OVS_WAIT_UNTIL([ip netns exec at_ns0 ping6 -c 1 fc00::2]) dnl HTTP requests from ns0->ns1 should work fine. NETNS_DAEMONIZE([at_ns1], [[$PYTHON $srcdir/test-l7.py http6]], [http0.pid]) @@ -1262,6 +1265,11 @@ table=1 priority=0, action=drop AT_CHECK([ovs-ofctl --bundle add-flows br0 flows.txt]) +dnl Linux seems to take a little time to get its IPv6 stack in order. Without +dnl waiting, we get occasional failures due to the following error: +dnl "connect: Cannot assign requested address" +OVS_WAIT_UNTIL([ip netns exec at_ns0 ping6 -c 1 fc00::2 >/dev/null]) + NETNS_DAEMONIZE([at_ns1], [[$PYTHON $srcdir/test-l7.py ftp]], [ftp0.pid]) dnl FTP requests from p0->p1 should work fine. @@ -1475,9 +1483,10 @@ priority=100,icmp6,icmp_type=136,action=normal AT_CHECK([ovs-ofctl --bundle add-flows br0 flows.txt]) -dnl Without this sleep, we get occasional failures due to the following error: +dnl Linux seems to take a little time to get its IPv6 stack in order. Without +dnl waiting, we get occasional failures due to the following error: dnl "connect: Cannot assign requested address" -sleep 2; +OVS_WAIT_UNTIL([ip netns exec at_ns0 ping6 -c 1 fc00::2]) dnl Basic connectivity check. NS_CHECK_EXEC([at_ns0], [ping6 -q -c 3 -i 0.3 -w 2 fc00::2 | FORMAT_PING], [0], [dnl @@ -1522,9 +1531,10 @@ priority=100,icmp6,icmp_type=136,action=normal AT_CHECK([ovs-ofctl --bundle add-flows br0 flows.txt]) -dnl Without this sleep, we get occasional failures due to the following error: +dnl Linux seems to take a little time to get its IPv6 stack in order. Without +dnl waiting, we get occasional failures due to the following error: dnl "connect: Cannot assign requested address" -sleep 2; +OVS_WAIT_UNTIL([ip netns exec at_ns0 ping6 -c 1 fc00::2]) dnl Basic connectivity check. NS_CHECK_EXEC([at_ns0], [ping6 -q -c 3 -i 0.3 -w 2 fc00::2 | FORMAT_PING], [0], [dnl @@ -1565,9 +1575,10 @@ priority=100,icmp6,icmp_type=136,action=normal AT_CHECK([ovs-ofctl --bundle add-flows br0 flows.txt]) -dnl Without this sleep, we get occasional failures due to the following error: +dnl Linux seems to take a little time to get its IPv6 stack in order. Without +dnl waiting, we get occasional failures due to the following error: dnl "connect: Cannot assign requested address" -sleep 2; +OVS_WAIT_UNTIL([ip netns exec at_ns0 ping6 -c 1 fc00::2]) dnl Basic connectivity check. NS_CHECK_EXEC([at_ns0], [ping6 -q -c 3 -i 0.3 -w 2 fc00:1::4 | FORMAT_PING], [0], [dnl @@ -1673,9 +1684,10 @@ ADD_OVS_TUNNEL([vxlan], [br0], [at_vxlan0], [172.31.1.1], ["fc00::2/96"]) ADD_NATIVE_TUNNEL([vxlan], [at_vxlan1], [at_ns0], [172.31.1.100], ["fc00::1/96"], [id 0 dstport 4789]) -dnl Without this sleep, we get occasional failures due to the following error: +dnl Linux seems to take a little time to get its IPv6 stack in order. Without +dnl waiting, we get occasional failures due to the following error: dnl "connect: Cannot assign requested address" -sleep 2; +OVS_WAIT_UNTIL([ip netns exec at_ns0 ping6 -c 1 fc00::2]) dnl First, check the underlay NS_CHECK_EXEC([at_ns0], [ping -q -c 3 -i 0.3 -w 2 172.31.1.100 | FORMAT_PING], [0], [dnl @@ -2224,9 +2236,10 @@ priority=200,in_port=2,ct_state=+trk+new,icmp6,icmpv6_code=0,icmpv6_type=135,nd_ AT_CHECK([ovs-ofctl --bundle add-flows br0 flows.txt]) -dnl Without this sleep, we get occasional failures due to the following error: +dnl Linux seems to take a little time to get its IPv6 stack in order. Without +dnl waiting, we get occasional failures due to the following error: dnl "connect: Cannot assign requested address" -sleep 2; +OVS_WAIT_UNTIL([ip netns exec at_ns0 ping6 -c 1 fc00::2]) dnl HTTP requests from ns0->ns1 should work fine. NETNS_DAEMONIZE([at_ns1], [[$PYTHON $srcdir/test-l7.py http6]], [http0.pid]) @@ -2280,6 +2293,11 @@ table=1 priority=0, action=drop AT_CHECK([ovs-ofctl --bundle add-flows br0 flows.txt]) +dnl Linux seems to take a little time to get its IPv6 stack in order. Without +dnl waiting, we get occasional failures due to the following error: +dnl "connect: Cannot assign requested address" +OVS_WAIT_UNTIL([ip netns exec at_ns0 ping6 -c 1 fc00::2 >/dev/null]) + NETNS_DAEMONIZE([at_ns1], [[$PYTHON $srcdir/test-l7.py ftp]], [ftp0.pid]) dnl FTP requests from p0->p1 should work fine.