cli: Backward compatibility for option names

[aravindavk]

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)

[ShyamsundarR]

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]

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]

@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 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