Bug 889996 - Volume is shown as started even if volume start fails on one of the peers in the cluster
Summary: Volume is shown as started even if volume start fails on one of the peers in ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: glusterd
Version: 2.0
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: ---
: ---
Assignee: Krutika Dhananjay
QA Contact: Shruti Sampat
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-24 09:58 UTC by Shruti Sampat
Modified: 2013-09-23 22:43 UTC (History)
4 users (show)

Fixed In Version: glusterfs-3.4.0.1rhs-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-23 22:39:24 UTC
Target Upstream Version:


Attachments (Terms of Use)
gluster logs from server where start fails (285.32 KB, text/x-log)
2012-12-24 09:58 UTC, Shruti Sampat
no flags Details
gluster logs from the other server (130.21 KB, text/x-log)
2012-12-24 09:59 UTC, Shruti Sampat
no flags Details

Description Shruti Sampat 2012-12-24 09:58:26 UTC
Created attachment 668425 [details]
gluster logs from server where start fails

Description of problem:
---------------------------------------
When volume start command is issued on one of the peers of the cluster, and it fails on another peer, the status of the volume is shown as started on the initiator even if the CLI output says that start failed. When volume stop command is issued, the following is seen as the output - 
---------------------------------------
volume stop: test: failed: Volume test is not in the started state

volume start on both peers now fails with the following output - 
---------------------------------------
volume start: test: failed: Volume test already started

Version-Release number of selected component (if applicable):
glusterfs 3.4.0qa5

How reproducible:
Always

Steps to Reproduce:
1. Create a distribute volume with 1 brick on each peer in a 2-node cluster.
2. On one of the peers, delete the brick directory.
3. Issue volume start command from the other peer (where brick directories are still present)
  
Actual results:
Volume is seen as started on one of the machines, while it is not started on the other machine.

Expected results:
The status of the volume should reflect the correct status, (in this case, not started) on both the peers.

Additional info:

Comment 1 Shruti Sampat 2012-12-24 09:59:19 UTC
Created attachment 668427 [details]
gluster logs from the other server

Comment 3 Vijay Bellur 2013-02-09 03:13:50 UTC
CHANGE: http://review.gluster.org/4365 (glusterd: harden 'volume start' staging to check for brick dirs' presence) merged in master by Anand Avati (avati@redhat.com)

Comment 4 Scott Haines 2013-03-08 21:04:00 UTC
Per 03/05 email exchange w/ PM, targeting for Big Bend.

Comment 5 Krutika Dhananjay 2013-04-16 11:59:52 UTC
Fixed in glusterfs-3.4.0.1rhs by the patch http://review.gluster.org/4365.

Hence moving the state of the bug to ON_QA.

Comment 6 Shruti Sampat 2013-04-30 11:04:26 UTC
Verified as fixed in glusterfs 3.4.0.1rhs. Volume status is now displayed correctly on all nodes.

Comment 7 Scott Haines 2013-09-23 22:39:24 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. 

For information on the advisory, and where to find the updated files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1262.html

Comment 8 Scott Haines 2013-09-23 22:43:43 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. 

For information on the advisory, and where to find the updated files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1262.html


Note You need to log in before you can comment on or make changes to this bug.