Can you elaborate on “will be using zkcli.sh”? Does that mean maybe in the not too distant future it won’t be used?
And in terms of the immediate future, okay to add bin/solr zk now, and zkcli.sh might need to be removed in Solr 11? > On Sep 14, 2023, at 2:11 PM, Houston Putman <hous...@apache.org> wrote: > >> Houston, would that work for the Solr-operator? I would be happy to work > with you to migrate the Solr-operator from zkcli.sh to bin/solr zk….. > > I'm not sure that the Solr Operator will be using zkcli.sh, but in general > the Solr Operator needs a 2 major version migration path. So if it supports > 8.11 and 9.x, the ZK command needs to exist in both. (either zkcli.sh or > bin/solr zk). So if you add "bin/solr zk" in 9.5 and remove "zkcli.sh" in > 10.0, that is a fairly big problem. Since the Solr Operator can't run both > the same way. > > - Houston > > On Fri, Aug 25, 2023 at 7:30 AM Eric Pugh <ep...@opensourceconnections.com > <mailto:ep...@opensourceconnections.com>> > wrote: > >> Thanks for going through this. >> >> Yeah, the TL;DR; is that we make sure that everything zkcli does is in the >> bin/solr zk command structure. Based on (somewhat painful) experience in >> other parts of the CLI, I think that we leave zkcli alone, as is for 9.x >> with no “improvements” to make life easier for folks. Port/upgrade >> bin/solr zk as needed. And then, remove zkcli in main. >> >> Houston, would that work for the Solr-operator? I would be happy to work >> with you to migrate the Solr-operator from zkcli.sh to bin/solr zk….. >> >> I’m excited about this because: >> 1) Ensures that we have parity in windows and osx without creating a >> zkcli.cmd ;-). >> 2) Reduces duplication of methods between the two. >> 3) Have consistency of the experience by not having multiple ways of >> calling zk. >> 4) If we start adding more auth to our CLI, then hopefully this picks it >> up for these zk operations ;-). <— Really not sure what that means. >> >>> On Aug 24, 2023, at 10:45 AM, Jason Gerlowski <gerlowsk...@gmail.com> >> wrote: >>> >>>> what commands that exist in zkcli are already covered with existing >> bin/solr zk subcommands, which maybe are no longer needed >>> >>> To clarify - you're thinking of removing functionality from zkcli if >>> there's already an equivalent in "bin/solr zk"? Or the opposite? >>> >>> I'm definitely rusty on this bit of the code, but my understanding was >>> that, in broad strokes: >>> - "bin/solr zk upconfig" == "zkcli.sh upconfig" >>> - "bin/solr zk downconfig" == "zkcli.sh downconfig" >>> - "bin/solr zk cp" == "zkcli.sh putfile" >>> - "bin/solr zk rm" == "zkcli.sh clear" >>> - "bin/solr zk mkroot" == "zkcli.sh bootstrap >>> >>> I think you'd need to look at each pair in detail though to see if >>> there aren't gaps. >>> >>>> which aspects of zkcli.sh people ACTUALLY use >>> >>> I use zkcli.sh's file manipulation commands ("put", "putfile", "get", >>> "getfile", "clear", and "ls") fairly often. I'm not sure if there's a >>> reason I've fallen into that pattern instead of using "bin/solr", or >>> whether there was a bug or feature gap that forced me into using >>> zkcli.sh >>> >>> One last note: don't forget that the solr operator uses zkcli.sh a >>> good bit on users' behalf. Particularly the "get", "clusterprop", and >>> "putfile" commands. >>> >>> Best, >>> >>> Jason >>> >>> On Mon, Aug 21, 2023 at 10:51 AM Eric Pugh >>> <ep...@opensourceconnections.com <mailto:ep...@opensourceconnections.com> >>> <mailto:ep...@opensourceconnections.com>> >> wrote: >>>> >>>> Hi all, I wanted to tap the braintrust to see what commands that exist >> in zkcli are already covered with existing bin/solr zk subcommands, which >> maybe are no longer needed, and which need porting over in some fashion. >>>> >>>> Looking at ZkCLITest.java, I see tests for: >>>> >>>> testBootstrapWithChroot - This appears to bootstrap a solr home and >> make the chroot in Zk. We have bin/solr zk upconfig, however it doesn’t >> do the chroot step, you have to bin/solr zk mkroot. We could change >> upconfig to have a chroot property, or just make it implicit that if you >> create a path that needs a chroot, then it does. >>>> >>>> testMakePath - Makes a path, and that appears to just duplicate >> bin/solr zk mkroot? Unless something special about roots? I wonder if >> “bin/solr zk mk” would be a better name? >>>> >>>> testPut - Just puts some random bytes. Bin/solr zk cp lets you copy >> files around, and appears to be similar. Do we need to keep this? >>>> >>>> testPutCompressed - Similar to the put, but compresses the file. Do we >> need this functionality? (I thought somewhere we do it on the fly or >> something??). It could be added I guess to bin/solr zk >>>> >>>> testPutFile - Similar to bin/solr zk cp with files. >>>> >>>> testPutFileCompressed - A compressed version of a file <— Do we need >> this? >>>> >>>> testList/ testLs - Similar to bin/solr zk ls >>>> >>>> testUpdateAcls - appears to have been needed at a point in time. Calls >> SolrZKClient.updateACLs(), which is also maybe called by ZkController, but >> maybe no longer needed? >>>> >>>> >>>> Interestingly there appears to some code to attempt to bootstrap a >> Zookeeper or maybe aspects of Solr if Solr isn’t actually running? >>>> >>>> Would love thoughts/feedback, any suggestions or ideas. Especially, >> which aspects of zkcli.sh people ACTUALLY use, because I’d love to migrate >> less rather than more ;-). >>>> >>>> Eric >>>> >>>> >>>> _______________________ >>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 >> | http://www.opensourceconnections.com >> <http://www.opensourceconnections.com/> < >> http://www.opensourceconnections.com/>< >> http://www.opensourceconnections.com/> | My Free/Busy < >> http://tinyurl.com/eric-cal> >>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw >>> >>>> This e-mail and all contents, including attachments, is considered to >> be Company Confidential unless explicitly stated otherwise, regardless of >> whether attachments are marked as such. >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>> <mailto:dev-unsubscr...@solr.apache.org> <mailto: >> dev-unsubscr...@solr.apache.org <mailto:dev-unsubscr...@solr.apache.org>> >>> For additional commands, e-mail: dev-h...@solr.apache.org >>> <mailto:dev-h...@solr.apache.org> <mailto: >> dev-h...@solr.apache.org <mailto:dev-h...@solr.apache.org>> >> _______________________ >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | >> http://www.opensourceconnections.com <http://www.opensourceconnections.com/> >> < >> http://www.opensourceconnections.com/> | My Free/Busy < >> http://tinyurl.com/eric-cal> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >> >> This e-mail and all contents, including attachments, is considered to be >> Company Confidential unless explicitly stated otherwise, regardless of >> whether attachments are marked as such. _______________________ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
