Erick Erickson created SOLR-14115:
-------------------------------------
Summary: Deprecate zkcli and bin/solr zk support
Key: SOLR-14115
URL: https://issues.apache.org/jira/browse/SOLR-14115
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: scripts and tools
Reporter: Erick Erickson
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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
