[Gluster-users] higher "op" version

[Kaushal M]

On 30-Jul-2013 10:26 PM, "Jay Vyas" <jayunit100 at gmail.com> wrote:
>
> It appears that some peer probes only work in one direction.
> Why is that the case?
>
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.
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.
> 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.
>
> Example..
>
> [root at hbase-regionserver3 ~]# gluster peer probe hbase-head
> peer probe: failed: Peer hbase-head is already at a higher op-version
>
This is the first type of probing described.
> [root at hbase-regionserver3 ~]# exit
>
> [root at hbase-master ~]# gluster peer probe hbase-regionserver3
> peer probe: success
>
This is the second case.
>
>
> --
> Jay Vyas
> http://jayunit100.blogspot.com
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users

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.
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.
There are 2 workarounds to this for now,
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.
2. Remove the 'operating-version' line from
/var/lib/glusterd/glusterd.infofile on the new peer. This will cause
the peer to start operating at the
minimum possible op-version, and it can then be probed.

(Now that I've written this here, I need to document this some place,
probably the gluster wiki.)

~kaushal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130731/be3da3d8/attachment.html>