Bug 818153 - [glusterfs-3.3.0qa39] - remove-brick commit force doesn't work as expected for a replicate volume.
[glusterfs-3.3.0qa39] - remove-brick commit force doesn't work as expected fo...
Status: CLOSED NOTABUG
Product: GlusterFS
Classification: Community
Component: cli (Show other bugs)
pre-release
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Amar Tumballi
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-02 06:51 EDT by M S Vishwanath Bhat
Modified: 2016-05-31 21:56 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-02 12:37:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description M S Vishwanath Bhat 2012-05-02 06:51:28 EDT
Description of problem:
I have a 3 node replicate volume. When I issue remove-brick to to make it 2 node replica, commit force just throws the usage message. remove-brick commit force should have removed the brick. But just remove-brick without any option works.

Version-Release number of selected component (if applicable):
glusterfs-3.3.0qa39

How reproducible:
Consistent

Steps to Reproduce:
1. Create and start a 3 node replicate volume. And create some data on the mountpoint.
2. Now run remove-brick <volname> <brick3> start
3. Then run remove-brick <volname> <brick3> status
4. remove-brick <volname> <brick3> commit
5. remove-brick <volname> <brick> commit force
  
Actual results:
I have pasted below the sequence of commands I executed and it's output

[root@QA-24 ~]# gluster v i

Volume Name: hosdu
Type: Replicate 
Volume ID: ca61fb62-5061-46db-bf29-be3561053874
Status: Started 
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: 172.17.251.63:/data/bricks/hosdu_brick1
Brick2: 172.17.251.66:/data/bricks/hosdu_brick2
Brick3: 172.17.251.65:/data/bricks/hosdu_brick3
Options Reconfigured:
diagnostics.count-fop-hits: on
diagnostics.latency-measurement: on

[root@QA-24 ~]# gluster v remove-brick hosdu 172.17.251.65:/data/bricks/hosdu_brick3 start
Remove Brick start successful

[root@QA-24 ~]# gluster v remove-brick hosdu 172.17.251.65:/data/bricks/hosdu_brick3 status
Volume hosdu is not a distribute volume or contains only 1 brick.
Not performing rebalance
[root@QA-24 ~]# gluster v remove-brick hosdu 172.17.251.65:/data/bricks/hosdu_brick3 commit
Removing brick(s) can result in data loss. Do you want to Continue? (y/n) y
use 'force' option as migration is in progress
[root@QA-24 ~]# gluster v remove-brick hosdu 172.17.251.65:/data/bricks/hosdu_brick3 commit force
wrong brick type: commit, use <HOSTNAME>:<export-dir-abs-path>
Usage: volume remove-brick <VOLNAME> [replica <COUNT>] <BRICK> ... {start|stop|status|commit|force}

I saw the rebalance process started in the <host3>. 

Expected results:
For a replicate volume rebalance shouldn't be started. So for remove-brick commit should not throw that error and commit force should actually commit the brick.
Comment 1 Amar Tumballi 2012-05-02 12:37:53 EDT
Vishwa,

This is the expected behavior. For the given use case, where you want to convert a replica(3) volume to replica(2) volume, please provide the command

gluster volume remove-brick <VOLNAME> replica 2 <BRICK> (and no need of start, status or commit).

If it doesn't work, re-open the bug.

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