<p dir="ltr"><br>
On 30-Jul-2013 10:26 PM, &quot;Jay Vyas&quot; &lt;<a href="mailto:jayunit100@gmail.com">jayunit100@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; It appears that some peer probes only work in one direction.  <br>
&gt; Why is that the case? <br>
&gt;<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&#39;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>
&gt; I guess the mystery lies in the &quot;op&quot; 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>

&gt;<br>
&gt; Example..<br>
&gt;<br>
&gt; [root@hbase-regionserver3 ~]# gluster peer probe hbase-head<br>
&gt; peer probe: failed: Peer hbase-head is already at a higher op-version<br>
&gt;<br>
This is the first type of probing described. <br>
&gt; [root@hbase-regionserver3 ~]# exit<br>
&gt;<br>
&gt; [root@hbase-master ~]# gluster peer probe hbase-regionserver3<br>
&gt; peer probe: success<br>
&gt;<br>
This is the second case. <br>
&gt;<br>
&gt;<br>
&gt; -- <br>
&gt; Jay Vyas<br>
&gt; <a href="http://jayunit100.blogspot.com">http://jayunit100.blogspot.com</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Gluster-users mailing list<br>
&gt; <a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
&gt; <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 &#39;operating-version&#39; 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&#39;ve written this here, I need to document this some place, probably the gluster wiki.)</p>
<p dir="ltr">~kaushal <br>
</p>