Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 818153 - [glusterfs-3.3.0qa39] - remove-brick commit force doesn't work as expected for a replicate volume.
Summary: [glusterfs-3.3.0qa39] - remove-brick commit force doesn't work as expected fo...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: GlusterFS
Classification: Community
Component: cli
Version: pre-release
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Amar Tumballi
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-05-02 10:51 UTC by M S Vishwanath Bhat
Modified: 2016-06-01 01:56 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-02 16:37:53 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

Description M S Vishwanath Bhat 2012-05-02 10:51:28 UTC
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 16:37:53 UTC
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.