[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lxc-devel
Subject:    [lxc-devel] [lxd/master] tests: Avoid event forwarding race condition
From:       stgraber on Github <lxc-bot () linuxcontainers ! org>
Date:       2019-07-23 23:26:20
Message-ID: 5d37979c.1c69fb81.67ad8.90feSMTPIN_ADDED_MISSING () mx ! google ! com
[Download RAW message or body]

[Attachment #2 (text/x-mailbox)]

The following pull request was submitted through Github.
It can be accessed and reviewed at: https://github.com/lxc/lxd/pull/6004

This e-mail was sent by the LXC bot, direct replies will not reach the author
unless they happen to be subscribed to this list.

=== Description (from pull-request) ===
There is a tiny potential race right between a cluster node joins and
the event forwarding being functional. If we immediately get requested
to do cross-node activity (in this case importing an image and creating
a container from it), there is a chance that one or multiple events
won't make it, leading to the client tool hanging (waiting for an event).

This problem should disappear when we rework event distribution to move
away from the current broadcast approach, at which point we can have
individual LXD nodes refuse to serve requests until they are connected
to the event hub.

Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>

[Attachment #3 (text/plain)]

From 6037c698f6a1e06bc7896ee55c50da9c9be01aa0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stéphane Graber?= <stgraber@ubuntu.com>
Date: Tue, 23 Jul 2019 19:20:42 -0400
Subject: [PATCH] tests: Avoid event forwarding race condition
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

There is a tiny potential race right between a cluster node joins and
the event forwarding being functional. If we immediately get requested
to do cross-node activity (in this case importing an image and creating
a container from it), there is a chance that one or multiple events
won't make it, leading to the client tool hanging (waiting for an event).

This problem should disappear when we rework event distribution to move
away from the current broadcast approach, at which point we can have
individual LXD nodes refuse to serve requests until they are connected
to the event hub.

Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>
---
 test/suites/clustering.sh | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/test/suites/clustering.sh b/test/suites/clustering.sh
index 5754e10152..659d96b066 100644
--- a/test/suites/clustering.sh
+++ b/test/suites/clustering.sh
@@ -831,6 +831,9 @@ test_clustering_publish() {
   ns2="${prefix}2"
   spawn_lxd_and_join_cluster "${ns2}" "${bridge}" "${cert}" 2 1 "${LXD_TWO_DIR}"

+  # Give LXD a couple of seconds to get event API connected properly
+  sleep 2
+
   # Init a container on node2, using a client connected to node1
   LXD_DIR="${LXD_TWO_DIR}" ensure_import_testimage
   LXD_DIR="${LXD_ONE_DIR}" lxc init --target node2 testimage foo

[Attachment #4 (text/plain)]

_______________________________________________
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic