Hide Forgot
Description of problem: Trying to add tcp transport type to already existing volume with rdma transport : gluster> volume info Volume Name: pirstripe Type: Stripe Status: Started Number of Bricks: 5 Transport-type: rdma Bricks: Brick1: gluster1:/export/gluster1/pirstripe Brick2: gluster2:/export/gluster2/pirstripe Brick3: gluster3:/export/gluster3/pirstripe Brick4: gluster4:/export/gluster4/pirstripe Brick5: gluster5:/export/gluster5/pirstripe Options Reconfigured: auth.allow: 10.2.178.* gluster> volume set pirstripe transport-type rdma,tcp Changing nfs transport type is allowed only for volumes of transport type tcp,rdma Set volume unsuccessful gluster> volume set pirstripe transport-type tcp,rdma Changing nfs transport type is allowed only for volumes of transport type tcp,rdma Set volume unsuccessful Version-Release number of selected component (if applicable): 3.3 beta 2 How reproducible: always Steps to Reproduce: 1. create a volume with rdma transport or just tcp transport 2. try to add tcp to existing volume that uses rdma or vice versa 3. Actual results: fails with strange nfs error Expected results: should add the correct tcp or rdma transport blocks to existing vol cfg files Additional info:
This is not supported with current versions. Will consider it as a feature request, as there exists a workaround 1) delete your rdma volume 2) create the volume with same bricks with both 'tcp,rdma' transport
If I delete the volume, I don't think gluster currently allows a re-create if the bricks have existing data in them right? Which brings up another feature request to have an option to force this if required. The workaround I used was to : 1) Create a test stripe volume that basically has the same setup except it has rdma,tcp 2) Turn glusterd and glusterfsd off 3) Add transport-type tcp,rdma to all the server .vol files 4) Create a <volname>.rdma-fuse.vol file in addition to the <volname>-fuse.vol similar to the test volume 5) In the info file, change transport-type to 2 6) Turn glusterd and glusterfsd on
@csb sysadmin, the bricks which were part of any volume have trusted.glusterfs.volume-id set to the volume-id as seen in 'gluster volume info'. This is not removed by glusterd on delete volume, to serve as a reminder to the administrator who can accidentally add the brick (which may still have old data, along with gfid from past life.) to a newly created volume. We expect the administrator to perform 'cleaning' of bricks using extras/clear_xattrs.sh (or any custom-made script), before the brick is made a part of any volume. As for the problem of not being able to change transport-type, I haven't managed to look into it yet. Will look into it and get back to you as early as possible.
http://review.gluster.org/4008 merged upstream...
Moving out of Big Bend since RDMA support is not available in Big Bend,2.1
Quality Engineering Management has reviewed and declined this request. You may appeal this decision by reopening this request.