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