Skip to content
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

Closed
samikshan opened this issue Dec 1, 2016 · 7 comments
Closed

Comments

@samikshan
Copy link
Contributor

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

@joejulian
Copy link
Member

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:

gluster volume get all cluster.max-op-version 

which would simply return a single entry with the max supported op-version, and

gluster volume get all cluster.max-op-version detail

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.

@atinmu
Copy link

atinmu commented Dec 13, 2016

I think the right place holder for this would be gluster volume status client and BZ 1302944 is what this RFE tracks with.

@joejulian
Copy link
Member

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.

@atinmu
Copy link

atinmu commented Dec 13, 2016

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.

@samikshan
Copy link
Contributor Author

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 volume status <VOLNAME|all> clients command output that currently provides us with the following information on clients:

  1. Brick name
  2. Client count for each brick
  3. hostname:port for each client
  4. Bytes read and written for each client

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.

@atinmu
Copy link

atinmu commented Jan 16, 2017

The patch is now into mainline.

@ShyamsundarR
Copy link
Contributor

Part of release-3.10 as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants