[Gluster-devel] op-version issues in the 3.5.1 beta release

[Niels de Vos]

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