[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=17842409#comment-17842409 ] ASF subversion and git services commented on SOLR-14115: Commit f1fc03fee039257172e257b79c82c2a742014525 in solr's branch refs/heads/main from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=solr.git;h=f1fc03fee03 ] SOLR-14115: Remove deprecated zkcli script. (#2427) Replaced by bin/solr sub command equivalents. > 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: 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-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[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=17842380#comment-17842380 ] ASF subversion and git services commented on SOLR-14115: Commit 9e13223e32901c77bda22e266a86ba1360f09fc9 in solr's branch refs/heads/branch_9x from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=solr.git;h=9e13223e329 ] SOLR-14115: Update the docs to reference to the bin/solr equivalent of the zkcli.sh (#2428) Didn't eliminate zookeeper-utilities.adoc as there may be an option to break up the solr-control-script-reference.adoc that became apparent in this commit, however saving for another day. > 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: 9.7 > > Time Spent: 1h 40m > 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-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[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=17842379#comment-17842379 ] ASF subversion and git services commented on SOLR-14115: Commit b530aa53e1e13deeb0fa99b7e58924de60317555 in solr's branch refs/heads/main from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=solr.git;h=b530aa53e1e ] SOLR-14115: Update the docs to reference to the bin/solr equivalent of the zkcli.sh (#2428) Didn't eliminate zookeeper-utilities.adoc as there may be an option to break up the solr-control-script-reference.adoc that became apparent in this commit, however saving for another day. > 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: 9.7 > > Time Spent: 1h 40m > 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-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[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=17841966#comment-17841966 ] ASF subversion and git services commented on SOLR-14115: Commit b93083e4ccbb0fb41657c85a1fff8925052a3d24 in solr's branch refs/heads/branch_9x from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=solr.git;h=b93083e4ccb ] SOLR-14115: Allow bin/solr zk commands to have parity with zkcli.sh commands. (#2298) Add updateacls, cluster, and linkconfig as standard Solr tools. Introduce some better testing of these relatively unknown tools. Keep zkcli.sh as is for the 9x branch of code. Some challenges around how we handle compression of state.json dealt with. > 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 > Time Spent: 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-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[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=17841963#comment-17841963 ] ASF subversion and git services commented on SOLR-14115: Commit 963b62983a9802789676903eeb6ac928c2d9b5aa in solr's branch refs/heads/main from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=solr.git;h=963b62983a9 ] SOLR-14115: Allow bin/solr zk commands to have parity with zkcli.sh commands. (#2298) Add updateacls, cluster, and linkconfig as standard Solr tools. Introduce some better testing of these relatively unknown tools. Keep zkcli.sh as is for the 9x branch of code. Some challenges around how we handle compression of state.json dealt with. > 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 > Time Spent: 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-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[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=17822964#comment-17822964 ] Eric Pugh commented on SOLR-14115: -- I noticed in [https://solr.apache.org/guide/solr/latest/deployment-guide/taking-solr-to-production.html#zookeeper-chroot] a reference to the "bootstrap" capablity. I feel like that is an older artifact that isn't used, and we never listed it as something to port to bin/solr zk subcommands. I'm not going to preserve it unless someone speaks up that it's actually a "good thing". It feels very opaque to use... and I suspect isn't actually used! > 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 > Time Spent: 40m > 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-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[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=17820763#comment-17820763 ] Eric Pugh commented on SOLR-14115: -- i am going to do the minium to get Cluster command done. However, it appears the bin/solr cluster could mimic the pattern of bin/solr config, and implement these apis.. https://solr.apache.org/guide/solr/latest/deployment-guide/cluster-node-management.html#clusterprop > 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 > Time Spent: 20m > 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-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[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=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: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[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=17726658#comment-17726658 ] Gus Heck commented on SOLR-14115: - There is an underlying ZkCli java class. What becomes of that? My Solr Gradle plugin relies on it... [https://github.com/nsoft/solr-gradle/blob/master/src/main/groovy/com/needhamsoftware/gradle/solr/SolrGradlePlugin.groovy#L38] > 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: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[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=17718103#comment-17718103 ] Jan Høydahl commented on SOLR-14115: The Solr operator uses the old zkcli script for certain things.. > 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: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[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=17718066#comment-17718066 ] Eric Pugh commented on SOLR-14115: -- Are all three of these commands that need adding to bin/solr zk still valid? Happy to do... > 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: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
