[jira] [Created] (SOLR-14115) Deprecate zkcli and bin/solr zk support

["Erick Erickson (Jira)" <ji...@apache.org>]

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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org