glusterd: generate node UUID lazily

A commonly faced problem among glusterfs users is: after a fresh
installation of glusterfs in a virtual machine, the VM image is
cloned to make multiple instances of the server. This breaks
glusterd because right after glusterfs installation on the first
boot glusterd would have created the node UUID and this gets
inherited into the clone. The result is wierd behavior at the time
of peer probe where glusterd does not (yet) deal with UUID
collisions in a user friendly way.

This patch is for the 'prevention' of the issue. The approach here
is to avoid generating a UUID on the first start of glusterd, but
instead generate a node UUID only when a node UUID is found to be
necessary. This naturally avoids the creation of node UUID on first
boot and prevents the issue to a large extent.

This issue also needs a 'cure' patch, which gives more meaningful
error messages to the user and provides CLI to recover from the
situations (gluster peer reset?)

Change-Id: Ieaaeeaf76ed35385844e98a8e23fc3dd8df5a208
BUG: 811493
Signed-off-by: Anand Avati <avati@redhat.com>
Reviewed-on: http://review.gluster.com/3533
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Jeff Darcy <jdarcy@redhat.com>

1 files changed, 1 insertions, 1 deletions

diff --git a/xlators/mgmt/glusterd/src/glusterd-log-ops.c b/xlators/mgmt/glusterd/src/glusterd-log-ops.c
index 93e037f8747..2056c84b53a 100644
--- a/xlators/mgmt/glusterd/src/glusterd-log-ops.c
+++ b/xlators/mgmt/glusterd/src/glusterd-log-ops.c
@@ -220,7 +220,7 @@ cont:
 
         ret = -1;
         list_for_each_entry (brickinfo, &volinfo->bricks, brick_list) {
-                if (uuid_compare (brickinfo->uuid, priv->uuid))
+                if (uuid_compare (brickinfo->uuid, MY_UUID))
                         continue;
 
                 if (brick &&