Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1109950

Summary: [feature] "gluster volume status" could report version
Product: [Community] GlusterFS Reporter: Joe Julian <joe>
Component: cliAssignee: Kaushal <kaushal>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: mainlineCC: amukherj, bugs, smohan
Target Milestone: ---Keywords: FutureFeature, Triaged
Target Release: ---   
Hardware: All   
OS: Unspecified   
Whiteboard:
Fixed In Version: glusterfs-4.1.3 (or higher) Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-08-29 03:18:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Joe Julian 2014-06-16 17:38:37 UTC
It would be a useful feature if "gluster volume status $vol clients" could report the version number of the clients and "gluster volume status version" could report the version of the servers. 

This would help ensure that the clients and servers are all at the expected version for change audits after upgrading.

Comment 1 Niels de Vos 2014-11-27 14:45:20 UTC
Feature requests make most sense against the 'mainline' release, there is no ETA for an implementation and requests might get forgotten when filed against a particular version.

Comment 2 Atin Mukherjee 2017-01-30 06:45:32 UTC
The first part of the request is now addressed through http://review.gluster.org/16303 and will be available as part of 3.10. On gluster v status version, we already have a cluster.op-version which indicates what op-version cluster is running with. On top of it we also introduced cluster.max-op-version (http://review.gluster.org/16283 ) which will indicate the version at which cluster can get bumped up to. IMHO, individual server options do not make much sense as GlusterD does all the client compatibility checks based on cluster.op-version.

Based on the above I am moving this bug to MODIFIED.

Comment 3 Joe Julian 2017-01-30 13:55:08 UTC
The sense of per server versions is that on several occasions I've encountered users that have installed multiple servers thinking they had installed them all from the ppa when, in fact, they had missed adding the ppa to one server. Even with cluster.max-op-version all we would know is that it's lower than expected. Showing the version for each server would easily show why that is.

Comment 4 Atin Mukherjee 2017-01-30 14:17:25 UTC
(In reply to Joe Julian from comment #3)
> The sense of per server versions is that on several occasions I've
> encountered users that have installed multiple servers thinking they had
> installed them all from the ppa when, in fact, they had missed adding the
> ppa to one server. Even with cluster.max-op-version all we would know is
> that it's lower than expected. Showing the version for each server would
> easily show why that is.

One can always use `gluster --version` in that case, no?

Comment 5 Joe Julian 2017-01-30 14:25:26 UTC
Yes, but that requires Nx operations vs one operation. Additionally, adding this feature would show servers that haven't restarted since upgrading and would just generally expose version problems faster and easier.