Red Hat Bugzilla – Bug 1260974
gdeploy: inconsistency in values expected for brick_dirs
Last modified: 2017-03-25 10:23:23 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
2. Run gdeploy: gdeploy -c gluster.conf
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
Error: brick_dirs should be relative to the mountpoint.
Looks like you have provided an absolute path. Exiting!
It should be consistent for all operations.
Fixed in commit https://github.com/gluster/gdeploy/commit/63167ac4bd710c18e76bd26ff690254a87171f07
Will be available with next build.
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.
(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.
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.
Verified with gdeploy-1.0-11.el6rhs.noarch