Open mbukatov opened 7 years ago
@mbukatov the current design is the brick_dirs are passed to gluster as is. And gluster takes care of creating brick directories. gdeploy creates only mount points.
The reason is, since gluster already takes care of creating brick directories we did not want to do the redundant work.
@sac Ok, thanks for the explanation. But I'm still little puzzled about the meaning of brick_dirs=
option in backend setup. What is it's meaning now when gluster handles this job? Should we remove it from the documentation? Also I would expect gluster to create those directories during setup of volume (gluster is now aware of any brick until one specify which bricks are part of a volume), right?
@mbukatov you are right about brick_dirs=
option being a confusion in backend_setup section. So, initially we had brick_dirs in backend-setup and when [volume]
section was mentioned it would use this information to create a volume.
And as the project evolved we moved the brick_dirs to [volume]
section and left the variable in [backend-setup] too to be backward compatible. However, the mistake was we did not set any deadline to remove the brick_dirs from backend-setup, and it stayed on. That is the story behind that variable.
We will keep this issue open till we deprecate that variable and eventually remove it.
When I use
[backed-setup]
feature to setup gluster bricks, brick directories are not created.Version
gdeploy-2.0.2-7.noarch (from sac-gdeploy copr)
Steps to Reproduce
gdeploy -c gluster_volume.conf
Actual Result
The lvm is configured as expected:
But I don't see any brick directory:
Expected Results
Brick directories has been created as well: