From http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/6699: Hi, today on IRC we has a discussion about the op-version for the current 3.5.1 beta. This beta includes a backport that introduces a new volume option (server.manage-gids) and needed to increase the op-version to prevent issues with systems that do not know about this new option. Currently, the op-version in 3.5.1 is (seems to be) hard-coded to '3': libglusterfs/src/globals.h:#define GD_OP_VERSION_MAX 3 Now, the new option required a glusterd with op-version=4. This worked fine when setting the option, and glusterd.info got updated too. Unfortunately, a restart of glusterd fails, because the op-version from the configuration is greater than the GD_OP_VERSION_MAX. Increasing GD_OP_VERSION_MAX is not really suitable, because op-version=4 would make other systems assume that the 3.5.1 release has all the op-version=4 features (incorrect, because the upcoming 3.6 has op-version=4). I see one option to fix this issue, that allows stable branches to include backports of volume options and similar, without conflicting with the development branch or newer versions: 1. define an op-version as multi-digit value, with gaps for stable releases 2. stable releases may only include backports of volume options that are in the development branch and newer versions 3. stable maintainers should pay extra care when new volume options are being backported The idea is the following: - update the hard-coded op-version in libglusterfs/src/globals.h in the master branch to 360 (based on the 3.6 release for easier matching) - update any options that have op-version >= 4 to 360 (master branch) - update the op-version in libglusterfs/src/globals.h in the release-3.5 branch to 351 - update the op-version of server.manage-gids option in 3.5.1 to 351 The only issue would be that current 3.6 packages in testing have a lower op-version than the new 3.5.1 packages. I hope it is not a common practise to have systems installed with packages from the master-branch in the same environment as 3.5.1 servers. Any ideas, suggestions or thoughts? If this can not be solved in a similar easy way, I will be forced to revert the 3.5.1 server.manage-gids option. Users were expecting this to be present so that deployments with many (ca. 93+) secondary groups have permissions working as expected. Thanks, Niels
Kaushal posted a 1st draft/rfc patch: - http://review.gluster.org/7963
REVIEW: http://review.gluster.org/7963 (glusterd: Better op-version values and ranges) posted (#2) for review on master by Kaushal M (kaushal)
COMMIT: http://review.gluster.org/7963 committed in master by Krishnan Parthasarathi (kparthas) ------ commit 66b99406a769a14b50aac2d077b5698b8be30aa6 Author: Kaushal M <kaushal> Date: Tue Jun 3 16:14:35 2014 +0530 glusterd: Better op-version values and ranges Till now, the op-version was an incrementing integer that was incremented by 1 for every Y release (when using the X.Y.Z release numbering). This is not flexible enough to handle backports of features into Z releases. Going forward, from the upcoming 3.6.0 release, the op-versions will be multi-digit integer values composed of the version numbers, instead of a simple incrementing integer. An X.Y.Z release will have XYZ as its op-version. Y and Z will always be 2 digits wide and will be padded with 0 if required. This way of bumping op-versions allows for gaps in between the subsequent Y releases. These gaps will allow backporting features from new Y releases into old Z releases. Change-Id: I463f82902d997ec07e76dae58ac935f33e6393c2 BUG: 1104997 Signed-off-by: Kaushal M <kaushal> Reviewed-on: http://review.gluster.org/7963 Reviewed-by: Niels de Vos <ndevos> Reviewed-by: Atin Mukherjee <amukherj> Tested-by: Gluster Build System <jenkins.com> Reviewed-by: Krishnan Parthasarathi <kparthas> Tested-by: Krishnan Parthasarathi <kparthas>
A beta release for GlusterFS 3.6.0 has been released. Please verify if the release solves this bug report for you. In case the glusterfs-3.6.0beta1 release does not have a resolution for this issue, leave a comment in this bug and move the status to ASSIGNED. If this release fixes the problem for you, leave a note and change the status to VERIFIED. Packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update (possibly an "updates-testing" repository) infrastructure for your distribution. [1] http://supercolony.gluster.org/pipermail/gluster-users/2014-September/018836.html [2] http://supercolony.gluster.org/pipermail/gluster-users/
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.6.1, please reopen this bug report. glusterfs-3.6.1 has been announced [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://supercolony.gluster.org/pipermail/gluster-users/2014-November/019410.html [2] http://supercolony.gluster.org/mailman/listinfo/gluster-users