<p dir="ltr"></p>
<p dir="ltr">-Atin<br>
Sent from one plus one<br>
On 20-Apr-2016 9:22 pm, "Dj Merrill" <<a href="mailto:gluster@deej.net">gluster@deej.net</a>> wrote:<br>
><br>
> On 04/19/2016 05:42 PM, Atin Mukherjee wrote:<br>
> >> After a brief search, I discovered the following solution for RHGS: <a href="https://access.redhat.com/solutions/2050753">https://access.redhat.com/solutions/2050753</a> It suggests updating the op-version of the cluster after the upgrade. There isn't any evidence of this procedure in the community documentation (except for in this mailing list).<br>
> >> ><br>
> >> > Unfortunately, nor 30709 or 30708 are valid op-version so I moved to 30707:<br>
> > Although the op-version numbering is aligned with the release versions<br>
> > but that doesn't go as a strict rule. If any new volume tunable option<br>
> > is introduced between the release then the op-version is bumped up.<br>
> > Between 3.7.7 and 3.7.9 releases there were no new options introduced<br>
> > and hence the op-version goes as 30707 for 3.7.9 release.<br>
><br>
><br>
> Curious, is there any reason why this isn't automatically updated when<br>
> managing the updates with "yum update"?<br>
This is still manual as we want to give users choose whether they want to use a new feature or not. If they want, then a manual bump up is required.<br>
><br>
> Just checked my system and it was set to "operating-version=2" even<br>
> though I have been on 3.7.x for awhile and just updated to 3.7.11.<br>
><br>
> I just ran "gluster volume set all cluster.op-version 30710" successfully.<br>
><br>
> What have I been missing all these years? :-)<br>
><br>
> Thanks,<br>
><br>
> -Dj<br>
><br>
><br>
> _______________________________________________<br>
> Gluster-users mailing list<br>
> <a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
> <a href="http://www.gluster.org/mailman/listinfo/gluster-users">http://www.gluster.org/mailman/listinfo/gluster-users</a><br>
</p>