Bug 1260974

Summary: gdeploy: inconsistency in values expected for brick_dirs
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Anush Shetty <ashetty>
Component: gdeployAssignee: Sachidananda Urs <surs>
Status: CLOSED CURRENTRELEASE QA Contact: Anush Shetty <ashetty>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rhgs-3.1CC: smohan
Target Milestone: ---Keywords: ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: gdeploy-1.0-10 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-03-25 14:23:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Anush Shetty 2015-09-08 10:30:06 UTC
Description of problem: If the bricks have to be setup, gdeploy expects [brick_dirs] values to be relative path along with the path provided for [mountpoints]. But when the brick mounts already exist, then it expects the [brick_dirs] to be absolute path.

Version-Release number of selected component (if applicable): gdeploy-1.0-8.el6rhs.noarch


How reproducible: Always

Steps to Reproduce:
1. Create a config file for setting up bricks:
 
gdeploy config: gluster.conf

[hosts]
rhshdp03.lab.eng.blr.redhat.com
rhshdp04.lab.eng.blr.redhat.com
rhshdp05.lab.eng.blr.redhat.com
rhshdp06.lab.eng.blr.redhat.com

[devices]
/dev/vdb

[mountpoints]
/gluster1/brick1/

[brick_dirs]
/gluster1/brick1/s1

[peer]
manage=probe

[volume]
action=create
volname=gluster_vol1
replica=yes
replica_count=2

2. Run gdeploy: gdeploy -c gluster.conf

Actual results:

Fails with the following message:

 gdeploy -k -c /opt/gluster.conf
/usr/lib/python2.6/site-packages/argparse.py:1575: DeprecationWarning: The "version" argument to ArgumentParser is deprecated. Please use "add_argument(..., action='version', version="N", ...)" instead
  """instead""", DeprecationWarning)
Error: brick_dirs should be relative to the mountpoint.
Looks like you have provided an absolute path. Exiting!

Expected results:

It should be consistent for all operations.

Comment 2 Nandaja Varma 2015-09-08 12:24:07 UTC
Fixed in commit https://github.com/gluster/gdeploy/commit/63167ac4bd710c18e76bd26ff690254a87171f07

Will be available with next build.

Comment 3 Nandaja Varma 2015-09-08 13:08:37 UTC
Now in both cases absolute path is to be given. In the back-end setup, though, one can still give absolute value since the initial path is already known from the mount point. In the volume creation from already existing back-end case, we have no way of knowing the absolute path, hence no relative path option.

Comment 4 Anush Shetty 2015-09-14 11:02:30 UTC
(In reply to Nandaja Varma from comment #3)
> Now in both cases absolute path is to be given. In the back-end setup,
> though, one can still give absolute value since the initial path is already
> known from the mount point. In the volume creation from already existing
> back-end case, we have no way of knowing the absolute path, hence no
> relative path option.

Do you mean that both absolute and relative paths are allowed? That is what it seems like.

Also, when [mountpoints] values are not given, and [brick_dirs] value is a relative path, the [mountpoints] value is taken to be default, i.e /gluster/brick1. 

Please confirm if this is the right behaviour.

Comment 5 Nandaja Varma 2015-09-14 11:21:20 UTC
yes. If back-end setup is there, we support both. It is just to make it a bit more flexible for the user.

And the second case you mentioned is the expected behavior. If absolute path is not given for brick_dirs and mountpoints is not given, it will take the default value.

Comment 6 Anush Shetty 2015-09-14 11:33:41 UTC
Verified with gdeploy-1.0-11.el6rhs.noarch