glusterfs.git/xlators/mgmt/glusterd/src/glusterd-log-ops.c, branch v3.4.4beta1

glusterd: do dict unref after sending reply to cli

2013-02-03T20:35:09+00:00

This patch channelizes dict unrefs of dictionaries created from the cli
req during volume ops to one common function - glusterd_to_cli() - which
is guaranteed to be called irrespective of whether the command succeeds
or fails.

This patch also removes extra unrefs at a few places.

Change-Id: Ic8ba7166387b5dfd1f5ae860539e1b7093a94662
BUG: 861044
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/4003
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi 
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

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

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

All: License message change

2012-08-28T10:45:06+00:00

The license message is changed to
  Copyright (c) 2008-2012 Red Hat, Inc. 
  This file is part of GlusterFS.

  This file is licensed to you under your choice of the GNU Lesser
  General Public License, version 3 or any later version (LGPLv3 or
  later), or the GNU General Public License, version 2 (GPLv2), in all
  cases as published by the Free Software Foundation.

Change-Id: I07d2b63ed5fbbbd1884f1e74f2dd56013d15b0f4
BUG: 852318
Signed-off-by: Varun Shastry 
Reviewed-on: http://review.gluster.org/3858
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

glusterd: Refactored brickinfo APIs

2012-07-19T16:09:33+00:00

This patch modifies the existing brickinfo function signatures
and/or names to do one thing right and call them by 'appropriate' names.

- Decoupled brickinfo_get and is_brickpath_available
- Removed dead comment about realpath(3) in canonicalize_path
- Renamed glusterd_brickinfo_from_brick to glusterd_brickinfo_new_from_brick
  to make the name of the function reflect that an allocation is happening

Change-Id: I29daba6d431ca799d43c927b9dfbaeda327e83e8
BUG: 764890
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.com/3668
Tested-by: Gluster Build System 
Reviewed-by: Amar Tumballi

remove useless if-before-free (and free-like) functions

2012-07-13T21:03:42+00:00

See comments in http://bugzilla.redhat.com/839925 for
the code to perform this change.

Signed-off-by: Jim Meyering 
BUG: 839925
Change-Id: I10e4ecff16c3749fe17c2831c516737e08a3205a
Reviewed-on: http://review.gluster.com/3661
Tested-by: Gluster Build System 
Reviewed-by: Anand Avati

glusterd: generate node UUID lazily

2012-06-08T00:35:34+00:00

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 
Reviewed-on: http://review.gluster.com/3533
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy