[SOLR-14115] Deprecate zkcli.sh

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: main (10.0), 9.7
• Component/s: scripts and tools
• Labels: pull-request-available
• Assignee: Eric Pugh
• Reporter: Erick Erickson
• Created: 18/Dec/19 18:23
• Updated: 06/Dec/24 14:41
• Resolved: 29/Apr/24 12:15

Description

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.

Issue Links

• breaks: SOLR-17586 Deprecation of zkcli.sh broke solr operator
• is related to: SOLR-7637 Improve error logging in the zkcli CLUSTERPROP command
• is related to: SOLR-16757 Umbrella Ticket for Revamping Solr CLI's for the Future
• links to: GitHub Pull Request #2298
• links to: GitHub Pull Request #2427
• links to: GitHub Pull Request #2428