Bug 1260974 - gdeploy: inconsistency in values expected for brick_dirs
gdeploy: inconsistency in values expected for brick_dirs
Status: CLOSED CURRENTRELEASE
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: gdeploy (Show other bugs)
3.1
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Sachidananda Urs
Anush Shetty
: ZStream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-08 06:30 EDT by Anush Shetty
Modified: 2017-03-25 10:23 EDT (History)
1 user (show)

See Also:
Fixed In Version: gdeploy-1.0-10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-03-25 10:23:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Anush Shetty 2015-09-08 06:30:06 EDT
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 08:24:07 EDT
Fixed in commit https://github.com/gluster/gdeploy/commit/63167ac4bd710c18e76bd26ff690254a87171f07

Will be available with next build.
Comment 3 Nandaja Varma 2015-09-08 09:08:37 EDT
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 07:02:30 EDT
(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 07:21:20 EDT
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 07:33:41 EDT
Verified with gdeploy-1.0-11.el6rhs.noarch

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