[
https://issues.apache.org/jira/browse/SOLR-14115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726801#comment-17726801
]
Eric Pugh commented on SOLR-14115:
----------------------------------
I did a bit of poking, and I think that there are a few options:
1) We leave org.apache.solr.cloud.ZkCLI alone. I don't think it's mentioned
much, and it can slowly die a lingering death.....
2) Migrate to using org.apache.solr.cli.ConfigSetUploadTool directly. No need
to call a main method.
3) Migrate to using org.apache.solr.cli.SolrCLI in the same way as you are
using org.apache.solr.cloud.ZkCLI.
4) Maybe we keep org.apache.solr.cloud.ZkCLI, but delegate it's calls to either
the SolrCLI or ConfigSetUploadTool (and other tools???). That feels like a
lot of indirection that will trip us up at some point....
My preferences would be either of 2 and 3 for updating the solr-gradle plugin.
Also, if the solr-operator needs the old zkcli for some things, I wonder if it
makes sense to move it over to that project?
> Deprecate zkcli.sh
> ------------------
>
> Key: SOLR-14115
> URL: https://issues.apache.org/jira/browse/SOLR-14115
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
> Reporter: Erick Erickson
> Priority: Major
>
> 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.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
