cb8e9e
From 25eaee83b236d1761a317d52bd4dd084275860a7 Mon Sep 17 00:00:00 2001
cb8e9e
From: Kaushal M <kaushal@redhat.com>
cb8e9e
Date: Fri, 10 Jul 2015 14:50:29 +0530
cb8e9e
Subject: [PATCH 229/234] glusterd: Send friend update even for EVENT_RCVD_ACC
cb8e9e
cb8e9e
In a multi-network cluster, a new peer being probed into the cluster
cb8e9e
will not get all the addresses of the peer that initiated the probe in
cb8e9e
some cases as it doesn't recieve friend updates from other peers in the
cb8e9e
cluster.
cb8e9e
cb8e9e
This happens when the new peer establishes connection with the other
cb8e9e
peers before the other peers connect to the new peer.
cb8e9e
cb8e9e
Assuming, F is the initiator peer, O is one of the other peers in the
cb8e9e
cluster and N is the new peer, the following series of events occur on O
cb8e9e
when N establishes the connection first. N is already in the BEFRIENDED
cb8e9e
state on O, and the actions happening will refer the BEFRIENDED state
cb8e9e
table.
cb8e9e
cb8e9e
  EVENT_RCV_FRIEND_REQ -> results in handle_friend_add_req being called
cb8e9e
                          which injects a LOCAL_ACC
cb8e9e
  EVENT_RCVC_LOCAL_ACC -> results in send_friend_update being called
cb8e9e
                          which should have sent an update to N, but O
cb8e9e
                          has still not established a connection to N,
cb8e9e
                          so the update isn't sent
cb8e9e
  EVENT_CONNECTED      -> O now connects to N, this results in O sending a
cb8e9e
                          friend_add req to N
cb8e9e
  EVENT_RCVD_ACC       -> friend_add_cbk inject this event, but this event
cb8e9e
                          results in a NOOP when in BEFRIENDED
cb8e9e
cb8e9e
As a result this O doesn't recieve all the addresses of F. If the
cb8e9e
cluster contains any volumes with bricks attached to the missing
cb8e9e
addresses of F and O is restarted in this condition, GlusterD will fail
cb8e9e
to start as it wouldn't be able to resolve those bricks.
cb8e9e
cb8e9e
This commit changes the EVENT_RCVD_ACC action for the BEFRIENDED state
cb8e9e
from a NOOP to send_friend_update. This makes sure that the new peer
cb8e9e
recieves the updates from the other existing peers, irrespective of who
cb8e9e
establishes the connection first, thus solving the problem.
cb8e9e
cb8e9e
BUG: 1234725
cb8e9e
Change-Id: I2bfb7f5e9456a792a15f09bd1ca58f6dc8f2fc1a
cb8e9e
Signed-off-by: Kaushal M <kaushal@redhat.com>
cb8e9e
Reviewed-upstream-on: https://review.gluster.org/11625
cb8e9e
Reviewed-on: https://code.engineering.redhat.com/gerrit/52812
cb8e9e
Reviewed-by: Atin Mukherjee <amukherj@redhat.com>
cb8e9e
Tested-by: Atin Mukherjee <amukherj@redhat.com>
cb8e9e
---
cb8e9e
 xlators/mgmt/glusterd/src/glusterd-sm.c |    2 +-
cb8e9e
 1 files changed, 1 insertions(+), 1 deletions(-)
cb8e9e
cb8e9e
diff --git a/xlators/mgmt/glusterd/src/glusterd-sm.c b/xlators/mgmt/glusterd/src/glusterd-sm.c
cb8e9e
index 902e770..e8e9b3a 100644
cb8e9e
--- a/xlators/mgmt/glusterd/src/glusterd-sm.c
cb8e9e
+++ b/xlators/mgmt/glusterd/src/glusterd-sm.c
cb8e9e
@@ -1024,7 +1024,7 @@ glusterd_sm_t  glusterd_state_befriended [] = {
cb8e9e
         {GD_FRIEND_STATE_BEFRIENDED, glusterd_ac_none}, //EVENT_NONE,
cb8e9e
         {GD_FRIEND_STATE_BEFRIENDED, glusterd_ac_none}, //EVENT_PROBE,
cb8e9e
         {GD_FRIEND_STATE_BEFRIENDED, glusterd_ac_none}, //EVENT_INIT_FRIEND_REQ,
cb8e9e
-        {GD_FRIEND_STATE_BEFRIENDED, glusterd_ac_none}, //EVENT_RCVD_ACC
cb8e9e
+        {GD_FRIEND_STATE_BEFRIENDED, glusterd_ac_send_friend_update}, //EVENT_RCVD_ACC
cb8e9e
         {GD_FRIEND_STATE_BEFRIENDED, glusterd_ac_send_friend_update}, //EVENT_RCVD_LOCAL_ACC
cb8e9e
         {GD_FRIEND_STATE_REJECTED, glusterd_ac_none}, //EVENT_RCVD_RJT
cb8e9e
         {GD_FRIEND_STATE_REJECTED, glusterd_ac_none}, //EVENT_RCVD_LOCAL_RJT
cb8e9e
-- 
cb8e9e
1.7.1
cb8e9e