New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support to get maximum op-version supported in a heterogeneous cluster #56
Comments
Would be helpful if this could also return the max op-version for each connected client as well, along with the client address. Perhaps a two-form version of this command:
which would simply return a single entry with the max supported op-version, and
Which would show the max op-version for each server and (known) client. This would aid quite a few users that have asked how to track down which client doesn't support the op-version necessary for any given command. |
I think the right place holder for this would be gluster volume status client and BZ 1302944 is what this RFE tracks with. |
If we're building a way to get the max op-version, the client op-version is every bit as important. When a configuration management tool queries so it can automatically set the op-version, it's best if it's all in one place. |
If we'd have to do that, then we shouldn't use the cluster name space here as that indicates the op-version (glusterd) of the cluster. |
The purpose that is served from getting the maximum supported op-version in a running cluster is to let the admin/user know the maximum op-version to which the cluster can be bumped up to so that new features can be accessed. Since this op-version bump up wouldn't really affect the clients, I believe it would be better to keep the max-op-version data for clients out of this particular feature. Having said that, the max-op-version data for clients can be added to the
http://review.gluster.org/#/c/16303/ aims to exactly do this by adding the maximum supported op-version in each client to the above list of data points. |
The patch is now into mainline. |
Part of release-3.10 as well. |
gluster volume get <volname> cluster.op-version
can provide the current op-version the cluster is running with. However there is no way for users to know the maximum value to which they can bump up the op-version. Given that auto op-version update doesn't happen on an upgrade, users might end up running the cluster with an older op-version. The focus area covered by this feature is 'user experience'Related bug in bugzilla: #1365822
The text was updated successfully, but these errors were encountered: