On Tue, Jun 03, 2014 at 04:46:17PM +0530, Kaushal M wrote: > I've sent out a draft/rfc patch on the master branch > http://review.gluster.org/7963. Thanks, looks good to me. I've filed bug 1104997 to track this. It's currently blocking the 2nd beta of glusterfs-3.5.1, so getting the fix in quickly is much appreciated. The 2nd beta is scheduled to be released later this week, or early in the next one. Niels > > ~kaushal > > On Tue, Jun 3, 2014 at 3:20 PM, Niels de Vos <ndevos@xxxxxxxxxx> wrote: > > On Tue, Jun 03, 2014 at 11:01:25AM +0530, Kaushal M wrote: > >> Niels, > >> This approach will work for well when the cluster is uniform, ie. of > >> the same (major) version. This could lead to problems in mixed > >> clusters when using volume set. Volume set compares the op-versions of > >> the options being set and will reject the set operation when the > >> op-versions are different. So, if a user were to run a mixed cluster > >> of gluster-3.5.1 and gluster-3.6.0, he wouldn't be able to set > >> server.manage-gids as its op-versions would be different. > > > > Thanks Kaushal, that is exactly my expectation. > > > >> But I don't expect anyone to be running such a cluster always. It > >> would mostly be during upgrades, during which users shouldn't be doing > >> volume operations. > > > > Yes, I agree. And it should be easy enough to diagnose 'volume set' > > issues when glusterfs versions are different. > > > > Would you like me to send a patch for the master branch that makes the > > changes mentioned below, or is that something you can do soon? I'll be > > waiting for the change to be merged before 3.5.1 can get the updated > > op-version for server.manage-gids. > > > > Thanks, > > Niels > > > >> > >> ~kaushal > >> > >> On Mon, Jun 2, 2014 at 8:28 PM, Niels de Vos <ndevos@xxxxxxxxxx> wrote: > >> > 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 > >> > _______________________________________________ > >> > Gluster-devel mailing list > >> > Gluster-devel@xxxxxxxxxxx > >> > http://supercolony.gluster.org/mailman/listinfo/gluster-devel _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
