<p dir="ltr"><br>
On 30-Jul-2013 10:26 PM, "Jay Vyas" <<a href="mailto:jayunit100@gmail.com">jayunit100@gmail.com</a>> wrote:<br>
><br>
> It appears that some peer probes only work in one direction. <br>
> Why is that the case? <br>
><br>
A peer already at a higher op-version possibly could have volumes which have newer features enabled. A cluster operating at a lower op-version wouldn't be able to support these volumes and hence will reject a peer of at a higher op-version. <br>
The other way round, with the cluster operating at higher op-version and the peer being probed operating at the lower op-version can succeed, provided that the peer supports the higher op-version. <br>
> I guess the mystery lies in the "op" version value. Not sure what that refers to - im using 3.4git, so I assume all versions should be the same even though the build dates are slightly off, because i build from source on all servers.<br>
><br>
> Example..<br>
><br>
> [root@hbase-regionserver3 ~]# gluster peer probe hbase-head<br>
> peer probe: failed: Peer hbase-head is already at a higher op-version<br>
><br>
This is the first type of probing described. <br>
> [root@hbase-regionserver3 ~]# exit<br>
><br>
> [root@hbase-master ~]# gluster peer probe hbase-regionserver3<br>
> peer probe: success<br>
><br>
This is the second case. <br>
><br>
><br>
> -- <br>
> Jay Vyas<br>
> <a href="http://jayunit100.blogspot.com">http://jayunit100.blogspot.com</a><br>
><br>
> _______________________________________________<br>
> Gluster-users mailing list<br>
> <a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
> <a href="http://supercolony.gluster.org/mailman/listinfo/gluster-users">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a></p>
<p dir="ltr">As I was writing this mail, I found a potential problem. With the current implementation, a freshly installed peer will start operating with the highest possible op-version, to be able to use all the new features at once. Because of this a newly installed peer, will not be able to join a freshly upgraded cluster.<br>
An upgraded peer will operate at the saved op-version if found, or the minimum op-version. This is to allow for the safe upgrade of all peers in a cluster, one at a time. Even after all peers are upgraded, the cluster will not move to the higher op-version automatically. The cluster op-version will be bumped only when a new feature is enabled. This is to allow older clients to continue working with the volumes in the cluster.<br>
There are 2 workarounds to this for now, <br>
1. Enable a new feature on any volume in the cluster, which will bump up the cluster op-version and allow it to probe the new peer. <br>
2. Remove the 'operating-version' line from /var/lib/glusterd/<a href="http://glusterd.info">glusterd.info</a> file on the new peer. This will cause the peer to start operating at the minimum possible op-version, and it can then be probed. </p>
<p dir="ltr">(Now that I've written this here, I need to document this some place, probably the gluster wiki.)</p>
<p dir="ltr">~kaushal <br>
</p>