You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "Chris M. Hostetter (Jira)" <ji...@apache.org> on 2024/05/03 17:30:00 UTC
[jira] [Commented] (SOLR-14115) Deprecate zkcli.sh
[ https://issues.apache.org/jira/browse/SOLR-14115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17843290#comment-17843290 ]
Chris M. Hostetter commented on SOLR-14115:
-------------------------------------------
Many (all?) of the test methods in {{ZkSubcommandsTest}} seem to be failing every 9x jenkins build since this test class was added last week.
I can reproduce locally, and seed does not seem to matter -- test just 100% doesn't work because it use an unsupported command line option????
Did the {{-r}} option not get backported to 9x (but the tests did?)
{noformat}
2> Failed to parse command-line arguments due to: Unrecognized option: -r
> java.lang.RuntimeException: SolrCLI failed to exit with status 1
> at __randomizedtesting.SeedInfo.seed([4CD8A90947D3CEB0:68BE0407CD1C78D6]:0)
> at org.apache.solr.cli.SolrCLI.exit(SolrCLI.java:125)
> at org.apache.solr.cli.SolrCLI.processCommandLineArgs(SolrCLI.java:348)
> at org.apache.solr.cli.SolrCLI.parseCmdLine(SolrCLI.java:177)
> at org.apache.solr.cli.ZkSubcommandsTest.runTool(ZkSubcommandsTest.java:698)
> at org.apache.solr.cli.ZkSubcommandsTest.testUpConfigLinkConfigClearZk(ZkSubcommandsTest.java:471)
...
2> Failed to parse command-line arguments due to: Unrecognized option: -r
> java.lang.RuntimeException: SolrCLI failed to exit with status 1
> at __randomizedtesting.SeedInfo.seed([4CD8A90947D3CEB0:CE2812CDC7431306]:0)
> at org.apache.solr.cli.SolrCLI.exit(SolrCLI.java:125)
> at org.apache.solr.cli.SolrCLI.processCommandLineArgs(SolrCLI.java:348)
> at org.apache.solr.cli.SolrCLI.parseCmdLine(SolrCLI.java:177)
> at org.apache.solr.cli.ZkSubcommandsTest.runTool(ZkSubcommandsTest.java:698)
> at org.apache.solr.cli.ZkSubcommandsTest.testInvalidZKAddress(ZkSubcommandsTest.java:630)
...
2> Failed to parse command-line arguments due to: Unrecognized option: -r
> java.lang.RuntimeException: SolrCLI failed to exit with status 1
> at __randomizedtesting.SeedInfo.seed([4CD8A90947D3CEB0:BCFD10BBD2258CFC]:0)
> at org.apache.solr.cli.SolrCLI.exit(SolrCLI.java:125)
> at org.apache.solr.cli.SolrCLI.processCommandLineArgs(SolrCLI.java:348)
> at org.apache.solr.cli.SolrCLI.parseCmdLine(SolrCLI.java:177)
> at org.apache.solr.cli.ZkSubcommandsTest.runTool(ZkSubcommandsTest.java:698)
> at org.apache.solr.cli.ZkSubcommandsTest.testLs(ZkSubcommandsTest.java:342)
{noformat}
> 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
> Assignee: Eric Pugh
> Priority: Major
> Fix For: main (10.0), 9.7
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> 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: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org