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

[David Smiley]

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

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

[Gus Heck]

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

subscribe

[Doug Coleman]

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

[David Eric Pugh]

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

Re: Overlapping arguments (SOLR-17383)

[David Eric Pugh]

 I've created PR's for all these tickets, 
https://github.com/apache/solr/pulls/epugh to see them.   
I'd love some review, and am hoping to merge them on my way to C/C NA tomorrow!

On Saturday, October 5, 2024 at 04:37:59 PM EDT, Christos Malliaridis 
 wrote:  
 
 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.

>