diff options
author | Atin Mukherjee <amukherj@redhat.com> | 2015-12-21 23:13:43 +0530 |
---|---|---|
committer | Atin Mukherjee <amukherj@redhat.com> | 2016-01-10 22:46:45 -0800 |
commit | c449b7520c6f1ac6ea1bc4119dbbbe9ebb80bf93 (patch) | |
tree | 740f47418c5e432c8691db5d15190ccfa035d06c /extras/hook-scripts | |
parent | 36fcaf275952202ce3f1e621d3b3a34d58054c99 (diff) | |
download | glusterfs-c449b7520c6f1ac6ea1bc4119dbbbe9ebb80bf93.tar.gz glusterfs-c449b7520c6f1ac6ea1bc4119dbbbe9ebb80bf93.tar.xz glusterfs-c449b7520c6f1ac6ea1bc4119dbbbe9ebb80bf93.zip |
glusterd: import/export brickinfo->uuid
Given a two node cluster with node N1 & N2, if a dummy node N3 is peer probed, the
probed node N3 goes for importing volumes from the probing node (N1), but
it still doesn't have information about the other node (N2) about its membership
(since peer update happens post volume updates) and hence fail to update its
brick's uuid. Post that even though N2 updates N3 about its membership the
brick's uuid was never generated. Now as a consequence when N3 initiates a
detach of N2, it checks whether the node to be detached has any bricks
configured by its respective uuid which is NULL in this case and hence it goes
ahead and removes the peer which ideally it shouldn't have (refer to
glusterd_friend_contains_vol_bricks () for the logic)
Fix is to export brick's uuid and import it at the probed node instead of
resolving it.
Change-Id: I2d88c72175347550a45ab12aff0ae248e56baa87
BUG: 1293414
Signed-off-by: Atin Mukherjee <amukherj@redhat.com>
Reviewed-on: http://review.gluster.org/13047
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Tested-by: NetBSD Build System <jenkins@build.gluster.org>
Reviewed-by: Gaurav Kumar Garg <ggarg@redhat.com>
Reviewed-by: Avra Sengupta <asengupt@redhat.com>
Diffstat (limited to 'extras/hook-scripts')
0 files changed, 0 insertions, 0 deletions