[Gluster-devel] op-version issues in the 3.5.1 beta release
Niels de Vos
ndevos at redhat.com
Mon Jun 2 14:58:16 UTC 2014
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
More information about the Gluster-devel
mailing list