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

cli: Backward compatibility for option names #739

Open
aravindavk opened this issue May 10, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@aravindavk
Copy link
Contributor

commented May 10, 2018

Since Glusterd2 loads list of xlator options directly from xlators/*.so files, it expects option name in volume set command as <xlator>.<option-name>. In previous releases name used in Volume set command is different that this(only <option-name>).

This may break many applications, tests and other integrations. APIs can continue to use the option names as Glusterd2 expects, CLI should convert old option name to new option name(excluding the ones which needs name change for usability)

aravindavk added a commit to aravindavk/glusterd2 that referenced this issue May 29, 2018

cli: Support Setting old Volume option names
Fixes: gluster#739
Signed-off-by: Aravinda VK <avishwan@redhat.com>

@aravindavk aravindavk referenced a pull request that will close this issue May 29, 2018

Open

cli: Support Setting old Volume option names #816

@aravindavk aravindavk added the FW: CLI label May 31, 2018

@ShyamsundarR

This comment has been minimized.

Copy link

commented Jul 10, 2018

Unsure which other issue to post this comment to, so using this one that talks about backward compatibility.

Comment originates from the review: https://review.gluster.org/#/c/20472/3 (see first comment by me and it's response). Tagging @prashanthpai as well here.

Questions and thoughts:

  • I understand that GD2 supports options such as [<graph>].<xlator>.<option-name>
  • Where <graph> is optional
  • What is the expectation if an option is specified without the <graph>, if we have <xlator> in multiple graphs? (io-stat is an example, client/server protocol would be another such)?
  • What is the expectation if an <xlator> appears more than once in a given <graph>? (examples could again be io-stats). Expectation would be that we can target the entire <xlator> in the <graph> or an instance of the same, how is this achieved?
  • Should we make <graph> optional at all? Or, if <graph> is not specified it means all xlator instance options are changed, then make a special case <graph> string such as "all" to ensure that the options are always set mentioning the graph that is being acted upon?
  • If we state <graph> as optional, is there a way to get a list of graphs for a given volume, so that users can use the values to set/get specific options?
@aravindavk

This comment has been minimized.

Copy link
Contributor Author

commented Jul 11, 2018

What is the expectation if an option is specified without the , if we have in multiple graphs? (io-stat is an example, client/server protocol would be another such)?

All volume set related to io-stat will be set under debug/io-stats, so whenever/wherever volgen sees type debug/io-stats then these options will be added to volfile.

Should we make optional at all? Or, if is not specified it means all xlator instance options are changed, then make a special case string such as "all" to ensure that the options are always set mentioning the graph that is being acted upon?

Makes sense, does glusterd1 supports this? my understanding was glusterd1 is acting as router user sees the option related to feature but internally it sets to respective xlator. For example, user sets "cluster.data-self-heal", but internally it is set to "replicate.data-self-heal". This avoids confusion if user thinks why he need to set "replicate.*" option when using disperse Volume.

We need enhancement in volgen, if options needs to be filtered based on graph type.

If we state as optional, is there a way to get a list of graphs for a given volume, so that users can use the values to set/get specific options?

Not yet available

@atinmu

This comment has been minimized.

Copy link
Contributor

commented Oct 30, 2018

@aravindavk - We need to get this addressed sooner so that we would be able to run the existing test suites from glusterfs (the xxx.t files) and all the Glusto test cases. We can have a discussion on this topic to see what are the current gaps and how soon we can address them.

@aravindavk

This comment has been minimized.

Copy link
Contributor Author

commented Oct 31, 2018

This now depends on Volgen template support(#1190 and #1111) and option set to support enable/disable xlators(#376). Once Volgen PR merges, I will work on #376

@aravindavk aravindavk added GCS/0.5 and removed GCS/0.5 labels Dec 13, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.