There is a bit of a convention to use “no” to turn something off. So we could have:
--cloud --no-cloud Or whatever is used instead of “cloud”. I could also go with --local-config vs --cloud-config. The use of a common config seems like the most fundamental part of solrcloud, that there is one config for all the nodes. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Oct 5, 2024, at 9:32 AM, David Smiley <dsmi...@apache.org> wrote: > > --disable-solrcloud ? My preference if we don't choose standalone > --legacy-mode I also like your suggestion here. > --classic-mode > > -1 to --single-node as surely anybody who didn't like "standalone" wouldn't > like this either as it's the same meaning, albeit a word we haven't used at > all and is even ambiguous with a single node SolrCloud, which is totally > valid. > -1 to any reference of "distributed" -- no way. "distributed" is way to > general a word, and lately has referred to disabling the Overseer, if you > didn't know. And Solr has supported "distributed search" years before > SolrCloud! Lets not forget that. > > On Sat, Oct 5, 2024 at 7:11 AM David Eric Pugh <de...@yahoo.com.invalid> > wrote: > >> To get the default change done... Is there another way to tell Solr >> that it's starting in a non solrcloud mode that would be a way to avoid >> wading into "standalone" and "user-managed". To get the default swap >> done, I need a flag I think! Unless someone has a creative idea of how to >> start Solr that wouldn't be in the SolrCloud mode... >> bin/solr start --not-solr-cloud-mode ??? >> bin/solr start --legagcy-mode >> bin/solr start --no-zookeeper >> bin/solr start --single-node >> bin/solr start --not-distributed-mode <--- I kind of don't mind this >> one. >> >> Or... And I don't really love it, we could add a start script specific >> to our non cloud mode. That goes against our goal of less custom shell >> scripts however and more Java code... >> >> bin/solr start_legacy >> bin/solr start_user_managed >> bin/solr start_single_node >> >> Or even, maybe a new start script for cloud and just document the heck out >> of it everywhere? >> bin/cluster >> bin/cloud <-- cloud is not a great name these days and we need to get rid >> of it. >> >> I don't know, lots of bikeshedding here. I think I can live with >> bin/solr start --not-distributed-mode. >> >> On Thursday, October 3, 2024 at 11:26:29 PM EDT, David Smiley < >> dsmi...@apache.org> wrote: >> >> Pluggability of ZK is a separate topic and you'll find it contentious >> since >> IMO it's a complete fantasy -- a massive effort for so little payoff. So >> let's not bring that up in this thread. >> >> Anyway, your last paragraph is the key part, and I agree but we're not >> there yet. Changing the default is clearly the next step -- thanks for >> that. Then, maybe reduce documentation on non-SolrCloud. Maybe assume >> SolrCloud and speak of "requires SolrCloud" without having to even name >> what non-SolrCloud is (Standalone vs User-Managed). >> >> On Thu, Oct 3, 2024 at 5:11 AM Eric Pugh <ep...@apache.org> wrote: >> >>> I am continuing to think about this.. Thanks David for reminding us on >>> https://issues.apache.org/jira/browse/SOLR-17468 about this thread. >>> >>> To uwe's point, someday we'll need to take what ZooKeeper does and make >> it >>> pluggable. For a single node Solr, it could be just a Hashmap that >>> supports the pluggable interface! And for a distributed system it could >>> be ZooKeeper. And for larger scale set ups, large parts of it might be >>> backed by something else. Or, we do the testing of what does embedded ZK >>> take, and decide it's okay. From my perspective, what scares me about >>> resource consumption in future versions of Solr isn't ZK, it's vectors >> and >>> models anyway ;-). >>> >>> I very much agree with the desire to have a single API surface, and that >>> is my long term goal. Streaming expressions? TRA? How to enable Basic >>> Auth and manage Security.json? They should all work the same regardless >> of >>> if you have 1 node or 10 nodes or 1000 nodes from an API and external >> user >>> perspective. With potentially different plumbing internally. >>> >>> If we succeed on that goal, then the whole "standalone" and "user >> managed" >>> and "cloud" goes away.. You just start your Solr's however you want and >>> cluster them (or not) however you want. It's not this big "mode" thing >>> anymore. >>> >>> >>> On 2024/02/29 13:49:47 Gus Heck wrote: >>>> @uwe >>>> >>>> With some rare exceptions command line startup for a production >>> environment >>>> is starting a single node per machine either way. You start a single >> node >>>> on a single machine and call it a day. Some folks start a single node >> on >>> 5 >>>> servers and point them at the same zookeeper. The only thing that is >>>> changing here is whether or not those people pass in -c or you pass in >>>> -standalone... (or -s :) ). >>>> >>>> The advantage of having you pass in -standalone (if that color is in >>>> fashion now) is that the tutorials can pass in less args, and be less >>>> complicated, and if SIP-14 gets finished people who want to take >>> advantage >>>> of it still don't have to pass in an arg. >>>> >>>> This change has zero impact on starting a new production anything other >>>> than tweaking a command line to add an arg. >>>> >>>> FWIW there are a few features not available without zk: Routed Aliases, >>>> Streaming expressions.... >>>> >>>> On Wed, Feb 28, 2024 at 4:36 PM Uwe Schindler <u...@thetaphi.de> wrote: >>>> >>>>> Hi, >>>>> >>>>> My problem is more: If you want to start a single Solr server, why >> the >>>>> hell do you want a zookeeper? This is total crap and waste of >> resources >>>>> and a security leak on top (why start some software that you don't >>> need?). >>>>> >>>>> I would agree with the new Solr Cloud default, if there would be by >>>>> default a test cluster started. But if it is only a single node: >>> please, >>>>> please, please default to standalone (yes that's the correct name) >>> mode. >>>>> Maybe make that dependent on what user wants: If you want to start a >>>>> test cluster start it in zookeper mode, if it's only one node start >> as >>>>> standalone. >>>>> >>>>> Speaking for many users... Thanks, Uwe >>>>> >>>>> P.S.: Instead of separating so hardly between incompatible solr cloud >>> vs >>>>> solr standalone: Make both behave identical API wise (e.g, remove the >>>>> differences between terms "collection" and "core"), but only start >> that >>>>> Zookeeper (shit) if you want more than one node by opt-in. >>>>> >>>>> Am 28.02.2024 um 19:19 schrieb Eric Pugh: >>>>>> This change is definitely NOT about requiring them to use Solr >>> Cloud…. >>>>>> >>>>>> We’ve changed the bin/solr script to require a “start” parameter, >> so >>>>> “bin/solr start” to fire up solr, so if you are used to "bin/solr", >> you >>>>> will need to learn the “bin/solr start” command. Though, if you are >>> using >>>>> install scripts, that probably doesn’t matter. >>>>>> >>>>>> For those who don’t want Solr Cloud, you just need to add a flag, >> so >>>>> “bin solr start -standalone” for example... >>>>>> >>>>>> >>>>>> >>>>>>> On Feb 28, 2024, at 12:55 PM, Uwe Schindler <u...@thetaphi.de> >>> wrote: >>>>>>> >>>>>>> Please no :-) 100% of my small/medium sized customers would never >>> ever >>>>> use Solr Cloud. >>>>>>> >>>>>>> Uwe >>>>>>> >>>>>>> Am 23.02.2024 um 19:06 schrieb Eric Pugh: >>>>>>>> During today’s community discussion the topic of moving to >>> defaulting >>>>> to SolrCloud mode came up. >>>>>>>> >>>>>>>> The idea here is that when a user run’s “bin/solr start” it fires >>> up >>>>> an embedded zookeeper. Same behavior as “bin/solr -c” in Solr 9.5. >>> If >>>>> you have a Zookeeper Ensemble then “bin/solr start -z YOUR_ZK_SETUP” >>> would >>>>> connect to the external ensemble instead. >>>>>>>> >>>>>>>> If you want to continue to use the class user managed mode, then >>>>> bin/solr start —user-managed maybe? Or bin/solr start —standalone >> ??? >>>>>>>> >>>>>>>> Other changes would be to go through the Ref Guide and where we >>> have >>>>> both SolrCloud and non SolrCloud content that we make sure SolrCloud >>>>> content is at the top instead of at the bottom. >>>>>>>> >>>>>>>> To me, this feels like a change that would go on main. >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> Eric >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________ >>>>>>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC >> <https://www.google.com/maps/search/OpenSource+Connections,+LLC+?entry=gmail&source=g> >> | >>> 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. >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Uwe Schindler >>>>>>> Achterdiek 19, D-28357 Bremen >>>>>>> https://www.thetaphi.de <https://www.thetaphi.de/> >>>>>>> eMail: u...@thetaphi.de <mailto:u...@thetaphi.de> >>>>>>> >>>>>>> >>>>>>> >>> --------------------------------------------------------------------- >>>> >> <https://www.google.com/maps/search/olr.apache.org++%3E+?entry=gmail&source=g>> >>>> To unsubscribe, e-mail: 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> >>>>>> _______________________ >>>>>> 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. >>>>>> >>>>>> >>>>> -- >>>>> Uwe Schindler >>>>> Achterdiek 19, D-28357 Bremen >>>>> https://www.thetaphi.de >>>>> eMail: u...@thetaphi.de >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>>> >>>>> >>>> >>>> -- >>>> http://www.needhamsoftware.com (work) >>>> https://a.co/d/b2sZLD9 (my fantasy fiction book) >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>> For additional commands, e-mail: dev-h...@solr.apache.org >>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
