glusterfs.git/xlators/mgmt/glusterd/src/glusterd-geo-rep.c, branch v3.4.0qa8

geo-rep / glusterd: do non-blocking connect to checkpoint service

2013-01-22T06:25:53+00:00

glusterd should not hang if gsyncd ends up in some weird state

Change-Id: Ic141daa0cd05d515848c8b6c25702418e15b7599
BUG: 826512
Signed-off-by: Csaba Henk 
Reviewed-on: http://review.gluster.org/3919
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

glusterd: Add GF_ASSERT check in glusterd volume op handlers

2013-01-09T07:58:41+00:00

Change-Id: Iea6ac1e612812ba8ffc4b60899a9e574a3b09ea6
BUG: 873549
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/4346
Reviewed-by: Pranith Kumar Karampuri 
Reviewed-by: Vijay Bellur 
Tested-by: Vijay Bellur

gsyncd / geo-rep: do not start geo-rep if replace brick is in progress

2012-12-12T00:26:52+00:00

Change-Id: I9db32544ceb6f90c8231aaf40d722f6869a72614
BUG: 861945
Signed-off-by: Venky Shankar 
Reviewed-on: http://review.gluster.org/4289
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

glusterd: log appropriate message when locking fails

2012-12-12T00:06:08+00:00

PROBLEM:

When a transaction is already in progress, and the user tries to
execute another glusterd operation, the second operation fails as
glusterd fails to acquire lock. But to the user, a message like
"Operation failed" does not give ample information about why the
operation failed.

FIX:

Made glusterd_op_txn_begin use and initialise error string, which is
needed to capture failure in the "lock" phase.

Also made gd_sync_task_begin set error string appropriately when
locking fails.

In the process, I had to introduce error string in some glusterd_handle_*
functions. And because I introduced error string in these handlers, I
decided to also set them in places where these handlers could possibly
fail.

HOW I TESTED IT:

For want of a better idea, I "commented out" the call to
"glusterd_unlock", recompiled glusterd and ran two glusterd volume
operations, one after the other. The second operation fails with the
message "Another transaction is in progress. Please try again after
sometime." as expected.

The tests were performed on two volume ops : one of them
synctask'ized (volume start) and the other NOT (volume create).

Change-Id: Ia862972929872ae2f053707a544824d9cadc37be
BUG: 873549
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/4197
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

Fix xdr_to_generic success check

2012-12-10T05:59:56+00:00

This patch fixes the success check for xdr_to_generic function across the
codebase.

Also, cleans up the brick_op actors table in glusterfsd-mgmt.c to make sure that
the actors are called directly by rpcsvc.

Change-Id: I3086585f30c44f69f1bc83665f89e30025f76d3a
BUG: 884452
Signed-off-by: Kaushal M 
Reviewed-on: http://review.gluster.org/4278
Reviewed-by: Pranith Kumar Karampuri 
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

geo-rep / gsyncd,glusterd: do not hardcode socket path

2012-11-29T00:54:07+00:00

... in gsyncd python code. Indeed, use the configuration
mechanism to set it suitably from glusterd.

Change-Id: I9fe2088b14d28588d1e64fe892740cc5755b8365
BUG: 868877
Signed-off-by: Csaba Henk 
Reviewed-on: http://review.gluster.org/4143
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

gsyncd / geo-rep: include hostname in status cmd

2012-11-22T00:49:04+00:00

Including hostname of the node where geo-rep start was
initiated from. This helps any consumers of the status
command to identify and possibly issue commands on those
node(s).

Change-Id: I005083878a3a4794da3b7f3f7d2cc9d28f004e3f
BUG: 858218
Signed-off-by: Venky Shankar 
Reviewed-on: http://review.gluster.org/4218
Reviewed-by: Csaba Henk 
Tested-by: Gluster Build System

glusterd: Fix to log command status at the appropriate time

2012-09-20T15:26:22+00:00

PROBLEM:
In the existing implementation, the success/failure of
execution of a command is decided (and logged) in glusterd
handler functions. Strictly speaking, the logging mechanism
must take into account what course the command takes within
the state machine before concluding whether it succeeded or
failed.

FIX:
This patch attempts to fix the above issue for vol commands.
The format of the log message is as follows:
    for failure:
     : FAILED : 
    for success:
     : SUCCESS

APPROACH (in a nutshell):

 * The command string is packed into dict at cli and sent to
   glusterd.
 * glusterd logs the command status just before doing a
   "submit_reply", which is called (either directly or
   indirectly via a call to glusterd_op_cli_send_response)
   at 2 places for every vol command:
   i. in handler functions, and
   ii. in glusterd_op_txn_complete

In short, the failure of a command in the handler implies the
command has indeed failed. However, its success in the handler
does NOT necessarily mean the command succeeded/will succeed.

Change-Id: I5a8a2ddc318ef2dc2a9699f704a6bcd2f0ab0277
BUG: 823081
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/3948
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

All: License message change

2012-09-13T20:19:37+00:00

License message changed for server-side, dual license GPLV2 and LGPLv3+.

Change-Id: Ia9e53061b9d2df3b3ef3bc9778dceff77db46a09
BUG: 852318
Signed-off-by: Varun Shastry 
Reviewed-on: http://review.gluster.org/3940
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Anand Avati

libglusterfs/dict: make 'dict_t' a opaque object

2012-09-06T07:34:15+00:00

* ie, don't dereference dict_t pointer, instead use APIs everywhere
* other than dict_t only 'data_t' should be the valid export from dict.h

* added 'dict_foreach_fnmatch()' API
* changed dict_lookup() to use data_t, instead of data_pair_t

Change-Id: I400bb0dd55519a7c5d2a107e67c8e7a7207228dc
Signed-off-by: Amar Tumballi 
BUG: 850917
Reviewed-on: http://review.gluster.org/3829
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati