Description of problem (on gluster 3.10.2): Some parts of GlusterFS require to know the GlusterFS version in order to function. For example, the gverify.sh script used in geo-replication fails if it cannot determine the version: https://github.com/gluster/glusterfs/blob/a35bfdaa6279a981a84e8831d65702496f1e478e/geo-replication/src/gverify.sh#L188 https://github.com/gluster/glusterfs/blob/a35bfdaa6279a981a84e8831d65702496f1e478e/geo-replication/src/gverify.sh#L192 The problem is that nothing in the GlusterFS build system checks that a version is really set. For example, when downloading a git commit or tag as a tarball from Github (such as https://github.com/gluster/glusterfs/archive/v3.10.2.tar.gz), then there is no .git directory, and there is also no VERSION file, but gluster will happily continue compiling, and `gluster --version` will simply contain "glusterfs" as the first line of output. This results in very cryptical error messages late at run-time, for example when setting up geo-replication, this can result in: Staging of operation 'Volume Geo-replication Create' failed on localhost : Unable to fetch master volume details. Please check the master cluster and master volume. when the problem is simply that the version is not set. The GlusterFS build system should check that the version is set, either by determining it from .git or from the VERSION file. If none of these 2 approaches have succeeded to determine a version, the build system should fail loudly.
This bug reported is against a version of Gluster that is no longer maintained (or has been EOL'd). See https://www.gluster.org/release-schedule/ for the versions currently maintained. As a result this bug is being closed. If the bug persists on a maintained version of gluster or against the mainline gluster repository, request that it be reopened and the Version field be marked appropriately.