Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
Description
I think it's a valid argument that these have outlived their usefulness and we should remove them and have APIs to do what Solr requires. Especially if we can find and point to a third-party visual ZK tool for changing arbitrary data in ZK. Zookeeper 3.5.5 has the admin server which has a UI (although I don't see how to change data in ZK with it. Haven't looked very much).
While we're ripping stuff out of Solr, are these candidates? It would break my heart to rip ZK support out from bin/solr, but all good things must come to an end. Why do we maintain three (zkcli, bin/solr and the APIs) ways of doing the same thing?
Mark put the zkcli stuff in before we had APIs to do what Solr needs to do with ZK, mainly uploading configsets at the time. I put the zk support in bin/solr also before the APIs existed because I thought having to learn our custom wrapper for ZK was yet another orphan bit of code laying around. All before we had things like the configsets API.
Personally, I'd prefer removing zkcli rather than bin/solr, but that's because I originated the bin/solr code
This occurred when reading SOLR-14109, I'm not entirely sure what I really think about it.
Attachments
Issue Links
- is related to
-
SOLR-7637 Improve error logging in the zkcli CLUSTERPROP command
- Resolved
-
SOLR-16757 Umbrella Ticket for Revamping Solr CLI's for the Future
- Open
- links to