Re: New Solr Admin UI - POC Presentation

[David Smiley]

Looking forward to it!

On Mon, Sep 30, 2024 at 2:02 AM Christos Malliaridis <
c.malliari...@gmail.com> wrote:

> Hello everyone,
>
> I would like to invite you all to the presentation about the proposal for a
> new Solr Admin UI.
>
> The presentation is about the content of the current proof-of-concept (POC)
> that introduces a new Admin UI written in Kotlin and Compose. The POC can
> be found at https://github.com/apache/solr/pull/2605.
>
> The presentation goes through concepts and libraries that are used and
> dives into the source code to show how the new Admin UI in the POC is
> structured and written in detail.
>
> If you are not a contributor but you consider to start contributing, this
> is a great opportunity for you to join the discussions and make your first
> contributions. The new Admin UI will be a new module in Apache Solr that
> aims to replace end-of-life code. You don't have to be skilled in
> programming to contribute to the new Solr Admin UI.
>
> If you are a contributor and you don't feel comfortable with frontend code,
> this is a great option to get familiar with it.
>
> I plan to hold the presentation twice:
>
>- On Monday, October 14, 2024 at 10:00 PST / 17:00 UTC
>invite link: https://calendar.app.google/NvYMnhrdMGs1Sjfk7
>- On Tuesday, October 15, 2024 at 10:00 PST / 17:00 UTC
>invite link: https://calendar.app.google/aR49NJ72MfdwKfcBA
>
> Read more about this Solr improvement proposal (SIP-7) at
>
> https://cwiki.apache.org/confluence/display/SOLR/SIP-7+Updated+Solr+Admin+UI
> .
>
> Best regards,
> Christos Malliaridis
>

Re: PR labeling

[Eric Pugh]

It was both great and sad to see a bunch of PR's closed.   I looked through, 
and there looked to be some nice fixes to various tests that are a shame to not 
get to done.  On the other hand being open means they didn't get to done 
either!   I like the "close-stale" label, this could let someone splunk around 
looking for some PR's that may be close but never quite ready to merge that 
could be completed.

I think this is a good step.

On 2024/09/29 21:43:32 Jan Høydahl wrote:
> Here is the PR: https://github.com/apache/solr/pull/2731
> Hope it captures the consensus in this thread.. Add a review comment if you 
> want to change something. Will leave it open for several days..
> 
> One thing to think about is what will happen with the 92 PRs that are 
> currently open and marked STALE.
> I counted, and 81 of those 92 are not updated last 60 days, so they'll 
> probably be bulk-closed on first run.
> That may not be an issue since they did not attract attention first time 
> around, and the close-message will also tell people that it is still possible 
> to re-open.
> But if we want to be extra cautios we could bulk-remove stale label for all 
> of them and let them trickle through the process again.
> I'm leaning towards letting them auto-close to avoid 81 mails for removing 
> labels, 81 new mails for stale-msg and then 81 mails for close-msg...
> 
> Jan
> 
> > 28. sep. 2024 kl. 13:50 skrev David Eric Pugh :
> > 
> > I haven't touch the labeling/workflow stuff, so I'd prefer not to make this 
> > change.  Jan, would this be up your alley?   I think we have agreement to 
> > try this!
> > 
> >On Tuesday, September 24, 2024 at 10:36:05 AM EDT, Mike Drob 
> >  wrote:  
> > 
> > I think this is a common sense of false optimism, that we will come back
> > and finish that PR we started. I too suffer from this frequently.
> > 
> > Why does it matter if the PR is open or closed though? Re-opening is a
> > single click, and after 6 months of zero activity it’s probably full of
> > merge conflicts anyway.
> > 
> > If we get to a workflow where open PRs roughly correspond to the direction
> > of the project then filtering out the false starts by closing them makes a
> > lot of sense to me.
> > 
> > Mike
> > 
> > On Tue, Sep 24, 2024 at 9:28 AM Jason Gerlowski 
> > wrote:
> > 
> >> +1 to try.
> >> 
> >> Especially if the attempt includes the "exempt PR" label feature that
> >> Eric linked to.  I'd use that pretty frequently in my workflow, as I
> >> often push code for feedback without knowing exactly when I'll be able
> >> to return to it and get it "over the finish line".
> >> 
> >> On Mon, Sep 23, 2024 at 10:46 AM David Smiley  wrote:
> >>> 
> >>> +1 to try
> >>> 
> >>> On Sun, Sep 22, 2024 at 3:43 PM Jan Høydahl 
> >> wrote:
> >>> 
>  +1 to try.
>  
>  60 days for stale and another 60 days before close should be enough
> >> imo.
>  
>  We can set the ‘close-pr-label’ for easier reference of what prs were
> >> auto
>  closed, should anyone wish to do archeology or re-open stuff that
> >> obviously
>  went below people’s radar despite two notifications to the list.
>  
>  Jan Høydahl
>  
> > On 22 Sep 2024, at 15:11, Eric Pugh  wrote:
> > 
> > What if we tried it for a few months and then reevaluated?
> > 
> > 
> > Sent from my iPhone
> > 
> >> On Sep 20, 2024, at 3:02 PM, Jan Høydahl 
> >> wrote:
> >> 
> >> Any commit or comment on a stale PR will make it un-stale for 60
> >> more
>  days too.
> >> 
> >> Jan Høydahl
> >> 
>  On 19 Sep 2024, at 23:14, David Smiley 
> >> wrote:
> >>> 
> >>> Upon seeing a "stale" warning, how do I signal to the bot that
> >> this PR
> >>> shouldn't be closed soon?  Or perhaps upon re-opening, the bot
> >> ought to
> >>> back off on this one forevermore?
> >>> 
> > On Thu, Sep 19, 2024 at 3:06 PM Jan Høydahl <
> >> jan@cominvent.com>
>  wrote:
>  
>  +1 I’ve tried suggesting this several times, also for abandoned
> >> JIRA
>  issues, but always big pushback.
>  
>  If we get a stale warning and then, if no one cares, another
>  notification
>  when auto-closing, no one can say they were not warned. And old
>  closed PRs
>  can always be re-opened, but at that point there will be so many
> >> merge
>  conflicts so who’d want to anyway? 😉
>  
>  Jan Høydahl
>  
> >> On 19 Sep 2024, at 20:07, David Smiley 
> >> wrote:
> > 
> > I don't see in the dev list here a discussion on auto-closing
> >> old
>  PRs
>  but
> > FWIW I'm in favor of that provided we could somehow choose to
> >> keep a
>  PR
> > open that we're still passionate about, that we don't want to be
> > forgotten.  This was discussed in the meetup yesterday.
> > 
> >> On Fri, Jan 26, 2024 at 10:56 AM Eric Pu

Re: Moving to bin/solr start defaulting to SolrCloud mode?

[David Eric Pugh]

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 
 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  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  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 wi

Re: Moving to bin/solr start defaulting to SolrCloud mode?

[David Smiley]

--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 
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  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 Sch

Re: Overlapping arguments (SOLR-17383)

[Christos Malliaridis]

We are almost done addressing all the overlapping issues I wanted to cover
in this series and we already solved multiple conflicts. I would like to
add the next resolutions in this message.

Right now, the common entrypoint for the tools is bin/solr(.cmd). This
includes the AssertTool, which uses single-letter names for many of its
options that are already used by other tools. Because of this, I created a
proposal for removing the single-letter names. Since the assert tool is
mainly used for testing, this should not impact user experience much. See
SOLR-17479 .

SOLR-17480  addresses the
option for setting solr.data.home, which uses different flags on bin/solr
and bin/solr.cmd. The ticket proposes to deprecate --solr-data and replace
it with --data-home, and to deprecate and remove -t, which is not obvious
and overlaps with --type/-t.

And the third ticket (SOLR-17481
) addresses -n, which is
used for --conf-name (multiple tools), --num-threads (SolrExporter) and
--no-prompt (RunExampleTool). Here, -n cannot be used for --no-prompt
through bin/solr(.cmd) and is therefore obsolete. The flag may be
simplified to --threads outside of this ticket in the future, simplifying
the input further to reduce the UX impact.

The last ticket in this message is SOLR-17482
, which aims to merge
--recurse/-r and --recursive/-r into the same option.

As usual, please speak up if you disagree with any of the proposals, so
that we can take additional perspectives into account during the CLI
migration.

>

Re: Moving to bin/solr start defaulting to SolrCloud mode?

[Walter Underwood]

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  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 
> 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  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 hav

Re: Moving to bin/solr start defaulting to SolrCloud mode?

[Walter Underwood]

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  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 
> 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  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 hav