On 8/2/2019 10:33 AM, Patrick Hunt wrote:
Right, it prints the membership of the quorum, see (for majority case which is typical): org.apache.zookeeper.server.quorum.flexible.QuorumMaj#toString https://github.com/apache/zookeeper/blob/faa7cec71fddfb959a7d67923acffdb67d93c953/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/flexible/QuorumMaj.java#L112
For our purposes (the Solr project) the output of the "conf" 4lw command is inconsistent, changing when there is a multi-server ensemble. All of the lines except the "membership: " one use an equals sign as a separator. Our parsing code fails on that line because there is no equals sign.
Whether or not the ZK project should consider this a bug is the question that I am asking.
While getting to the bottom of that question, another one arises: Who are the intended audiences of the "conf" 4lw output? If one of those audiences is ZK itself, then the output of the command probably will work perfectly for that audience, as ZK uses Java's "properties" API to read its config file, which means that both = and : will work as separators.
The current output also works great for a human audience. Humans are quite flexible.
The difficulty is machine-based parsers like the one in Solr, which is very simple and just splits lines on an equal sign. How much consistency can an audience like this expect? I would personally say that the way "membership: " is output is a bug. That line probably should be entirely removed, or the colon could be replaced with an equal sign. I think that the line only makes sense for a human audience, and that audience probably doesn't really need it.
An alternate path: One statement in the documentation would remove all difficulty, without any code changes in ZK:
"The output from the conf 4lw command should be parsed by the Java Properties API for best results."
If that statement is added, then Solr just needs to utilize the Properties API, which is very easy to do, and all is well again.
So... I'm thinking we should open an issue in Jira, and then leave it up to the ZK committers whether it's better to change the output or adjust the documentation. I can supply a patch either way. What does the community think?
Thanks, Shawn