Yeah, basically lean on SolrCloud vs non-SolrCloud and avoid as much as possible a name for non-SolrCloud.
That said, I'm sure inside the codebase we have classes/comments referring to "standalone", and I don't think it's a bad thing for us maintainers. We know what this is :-) A renaming to "NonCloud" would sound clumsy IMO but it's not a big deal. A quick search: https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/handler/component/StandaloneReplicaSource.java https://github.com/apache/solr/blob/main/solr/prometheus-exporter/src/java/org/apache/solr/prometheus/scraper/SolrStandaloneScraper.java and 5 tests. Some methods too. On Mon, Oct 7, 2024 at 12:59 PM Gus Heck <gus.h...@gmail.com> wrote: > Since we're here again, I like walter's suggestion. > > --cloud > --no-cloud > > The attraction of this (to me at least) is that although "cloud" in Solr > Cloud is a misnomer, "Solr Cloud" is the well known and popular name that > everyone recognizes. Nobody will need to think to figure out what this > option means. Until such time as we completely rebrand the product we > should focus on usability and user friendliness, for which this is a clear > winner (in my opinion at least)... and this command line cleanup is not the > place to rebrand the whole product. > > On Mon, Oct 7, 2024 at 11:16 AM David Eric Pugh <de...@yahoo.com.invalid> > wrote: > > > --legacy may be too strong a phrase, so leaning towards --classic as the > > parameter? Will update the related PR's and see how they look. > > I'd love to get this to done this week if possible. If that's rushing > > things, let me know. > > > > On Saturday, October 5, 2024 at 12:32:53 PM EDT, 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 > > > > > > > > > > > > > > > > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) >
