Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Bram Van Dam]

On 28/06/2020 14:42, Erick Erickson wrote:
> We need to draw a sharp distinction between standalone “going away”
> in terms of our internal code and going away in terms of the user
> experience.

It'll be hard to make it completely transparant in terms of user
experience. For instance, tere is currently no way to unload a core in
SolrCloud (without deleting it). I'm sure there are many other similar
gotchas.

 - Bram

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Mark H. Wood]

Wandering off topic, but still apropos Solr.

On Sun, Jun 28, 2020 at 12:14:56PM +0200, Ilan Ginzburg wrote:
> I disagree Ishan. We shouldn't get rid of standalone mode.
> I see three layers in Solr:
> 
>1. Lucene (the actual search libraries)
>2. The server infra ("standalone Solr" basically)
>3. Cluster management (SolrCloud)
> 
> There's value in using lower layers without higher ones.
> SolrCloud is a good solution for some use cases but there are others that
> need a search server and for which SolrCloud is not a good fit and will
> likely never be. If standalone mode is no longer available, such use cases
> will have to turn to something other than Solr (or fork and go their own
> way).

A data point:

While working to upgrade a dependent product from Solr 4 to Solr 7, I
came across a number of APIs which would have made things simpler,
neater and more reliable...except that they all are available *only*
is SolrCloud.  I eventually decided that asking thousands of sites to
run "degenerate" SolrCloud clusters (of a single instance, plus the ZK
stuff that most would find mysterious) was just not worth the gain.

So, my wish-list for Solr includes either (a) abolish standalone so
the decision is taken out of my hands, or (b) port some of the
cloud-only APIs back to the standalone layer.  I haven't spent a
moment's thought on how difficult either would be -- as I said, just a
wish.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Jan Høydahl]

Please start another thread to discuss removal of standalone mode, and stay 
on-topic in this one.


> 28. jun. 2020 kl. 14:42 skrev Erick Erickson :
> 
> We need to draw a sharp distinction between standalone “going away”
> in terms of our internal code and going away in terms of the user
> experience.
> 
> Usually when we’re talking about standalone going a way, it’s the
> former. The assumption is that we’ll use an embedded ZK that
> fires up automatically so Solr behaves very similarly to how it
> behaves in the current standalone mode just without all the 
> if (zkHost == null) do_something else do_something_else
> 
> I wonder it the slickest way to use embedded ZK would be to
> populate the embedded ZK during core discovery
> 
> Erick
> 
> 
> 
>> On Jun 28, 2020, at 6:40 AM, Ishan Chattopadhyaya 
>>  wrote:
>> 
>> Cost of maintaining feature parity across the two modes is an overhead.
>> Security plugins, package manager (that doesn't work in standalone), UI,
>> etc. Our codebase is littered with checks to ascertain if we're zkAware.
>> There are massive benefits to maintainability if standalone mode were to go
>> away. Of course, provided all usecases that could be solved using
>> standalone can also be solved using SolrCloud. At that point, I'd love for
>> us to get rid of the term "SolrCloud".
>> 
>> On Sun, 28 Jun, 2020, 3:59 pm Ishan Chattopadhyaya, <
>> ichattopadhy...@gmail.com> wrote:
>> 
>>> I would like to know under which situations (except for the various bugs
>>> that will be fixed eventually) would a SolrCloud solution not suffice.
>>> AFAICT, pull replicas and tlog replicas can provide similar replication
>>> strategies commonly used with standalone Solr. I understand that running ZK
>>> is an overhead and SolrCloud isn't best written when it comes to handling
>>> ZK, but that can be improved.
>>> 
>>> And for those users who just want a single node Solr, they can just start
>>> Solr with embedded ZK. It won't practically make difference.
>>> 
>>> On Sun, 28 Jun, 2020, 3:45 pm Ilan Ginzburg,  wrote:
>>> 
 I disagree Ishan. We shouldn't get rid of standalone mode.
 I see three layers in Solr:
 
  1. Lucene (the actual search libraries)
  2. The server infra ("standalone Solr" basically)
  3. Cluster management (SolrCloud)
 
 There's value in using lower layers without higher ones.
 SolrCloud is a good solution for some use cases but there are others that
 need a search server and for which SolrCloud is not a good fit and will
 likely never be. If standalone mode is no longer available, such use cases
 will have to turn to something other than Solr (or fork and go their own
 way).
 
 Ilan
 
 On Sat, Jun 27, 2020 at 9:39 PM Ishan Chattopadhyaya <
 ichattopadhy...@gmail.com> wrote:
 
> Rather than getting rid of the terminology, we should get rid of the
> standalone mode Solr altogether. I totally understand that SolrCloud is
> broken in many ways today, but we should attempt to fix it and have it
 as
> the only mode in Solr.
> 
> On Wed, 24 Jun, 2020, 8:17 pm Mike Drob,  wrote:
> 
>> Brend,
>> 
>> I appreciate that you are trying to examine this issue from multiple
> sides
>> and consider future implications, but I don’t think that is a stirring
>> argument. By analogy, if we are out of eggs and my wife asks me to go
 to
>> the store to get some, refusing to do so on the basis that she might
 call
>> me while I’m there and also ask me to get milk would not be
 reasonable.
>> 
>> What will come next may be an interesting question philosophically,
 but
> we
>> are not discussing abstract concepts here. There is a concrete issue
>> identified, and we’re soliciting input in how best to address it.
>> 
>> Thank you for the suggestion of "guide/follower"
>> 
>> Mike
>> 
>> On Wed, Jun 24, 2020 at 6:30 AM Bernd Fehling <
>> bernd.fehl...@uni-bielefeld.de> wrote:
>> 
>>> I'm following this thread now for a while and I can understand
>>> the wish to change some naming/wording/speech in one or the other
>>> programs but I always get back to the one question:
>>> "Is it the weapon which kills people or the hand controlled by
>>> the mind which fires the weapon?"
>>> 
>>> The thread started with slave - slavery, then turned over to master
>>> and followed by leader (for me as a german... you know).
>>> What will come next?
>>> 
>>> And more over, we now discuss about changes in the source code and
>>> due to this there need to be changes to the documentation.
>>> What about the books people wrote about this programs and source
 code,
>>> should we force this authors to rewrite their books?
>>> May be we should file a request to all web search engines to reject
>>> all stored content about these "banned" words?
>>> And 

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Erick Erickson]

We need to draw a sharp distinction between standalone “going away”
in terms of our internal code and going away in terms of the user
experience.

Usually when we’re talking about standalone going a way, it’s the
former. The assumption is that we’ll use an embedded ZK that
fires up automatically so Solr behaves very similarly to how it
behaves in the current standalone mode just without all the 
if (zkHost == null) do_something else do_something_else

I wonder it the slickest way to use embedded ZK would be to
populate the embedded ZK during core discovery

Erick



> On Jun 28, 2020, at 6:40 AM, Ishan Chattopadhyaya  
> wrote:
> 
> Cost of maintaining feature parity across the two modes is an overhead.
> Security plugins, package manager (that doesn't work in standalone), UI,
> etc. Our codebase is littered with checks to ascertain if we're zkAware.
> There are massive benefits to maintainability if standalone mode were to go
> away. Of course, provided all usecases that could be solved using
> standalone can also be solved using SolrCloud. At that point, I'd love for
> us to get rid of the term "SolrCloud".
> 
> On Sun, 28 Jun, 2020, 3:59 pm Ishan Chattopadhyaya, <
> ichattopadhy...@gmail.com> wrote:
> 
>> I would like to know under which situations (except for the various bugs
>> that will be fixed eventually) would a SolrCloud solution not suffice.
>> AFAICT, pull replicas and tlog replicas can provide similar replication
>> strategies commonly used with standalone Solr. I understand that running ZK
>> is an overhead and SolrCloud isn't best written when it comes to handling
>> ZK, but that can be improved.
>> 
>> And for those users who just want a single node Solr, they can just start
>> Solr with embedded ZK. It won't practically make difference.
>> 
>> On Sun, 28 Jun, 2020, 3:45 pm Ilan Ginzburg,  wrote:
>> 
>>> I disagree Ishan. We shouldn't get rid of standalone mode.
>>> I see three layers in Solr:
>>> 
>>>   1. Lucene (the actual search libraries)
>>>   2. The server infra ("standalone Solr" basically)
>>>   3. Cluster management (SolrCloud)
>>> 
>>> There's value in using lower layers without higher ones.
>>> SolrCloud is a good solution for some use cases but there are others that
>>> need a search server and for which SolrCloud is not a good fit and will
>>> likely never be. If standalone mode is no longer available, such use cases
>>> will have to turn to something other than Solr (or fork and go their own
>>> way).
>>> 
>>> Ilan
>>> 
>>> On Sat, Jun 27, 2020 at 9:39 PM Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>> 
 Rather than getting rid of the terminology, we should get rid of the
 standalone mode Solr altogether. I totally understand that SolrCloud is
 broken in many ways today, but we should attempt to fix it and have it
>>> as
 the only mode in Solr.
 
 On Wed, 24 Jun, 2020, 8:17 pm Mike Drob,  wrote:
 
> Brend,
> 
> I appreciate that you are trying to examine this issue from multiple
 sides
> and consider future implications, but I don’t think that is a stirring
> argument. By analogy, if we are out of eggs and my wife asks me to go
>>> to
> the store to get some, refusing to do so on the basis that she might
>>> call
> me while I’m there and also ask me to get milk would not be
>>> reasonable.
> 
> What will come next may be an interesting question philosophically,
>>> but
 we
> are not discussing abstract concepts here. There is a concrete issue
> identified, and we’re soliciting input in how best to address it.
> 
> Thank you for the suggestion of "guide/follower"
> 
> Mike
> 
> On Wed, Jun 24, 2020 at 6:30 AM Bernd Fehling <
> bernd.fehl...@uni-bielefeld.de> wrote:
> 
>> I'm following this thread now for a while and I can understand
>> the wish to change some naming/wording/speech in one or the other
>> programs but I always get back to the one question:
>> "Is it the weapon which kills people or the hand controlled by
>> the mind which fires the weapon?"
>> 
>> The thread started with slave - slavery, then turned over to master
>> and followed by leader (for me as a german... you know).
>> What will come next?
>> 
>> And more over, we now discuss about changes in the source code and
>> due to this there need to be changes to the documentation.
>> What about the books people wrote about this programs and source
>>> code,
>> should we force this authors to rewrite their books?
>> May be we should file a request to all web search engines to reject
>> all stored content about these "banned" words?
>> And contact all web hosters about providing bad content.
>> 
>> To sum things up, within my 40 years of computer science and writing
>> programs I have never had a nanosecond any thoughts about words
>> like master, slave, leader, ... other than thinking about computers

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Ishan Chattopadhyaya]

Cost of maintaining feature parity across the two modes is an overhead.
Security plugins, package manager (that doesn't work in standalone), UI,
etc. Our codebase is littered with checks to ascertain if we're zkAware.
There are massive benefits to maintainability if standalone mode were to go
away. Of course, provided all usecases that could be solved using
standalone can also be solved using SolrCloud. At that point, I'd love for
us to get rid of the term "SolrCloud".

On Sun, 28 Jun, 2020, 3:59 pm Ishan Chattopadhyaya, <
ichattopadhy...@gmail.com> wrote:

> I would like to know under which situations (except for the various bugs
> that will be fixed eventually) would a SolrCloud solution not suffice.
> AFAICT, pull replicas and tlog replicas can provide similar replication
> strategies commonly used with standalone Solr. I understand that running ZK
> is an overhead and SolrCloud isn't best written when it comes to handling
> ZK, but that can be improved.
>
> And for those users who just want a single node Solr, they can just start
> Solr with embedded ZK. It won't practically make difference.
>
> On Sun, 28 Jun, 2020, 3:45 pm Ilan Ginzburg,  wrote:
>
>> I disagree Ishan. We shouldn't get rid of standalone mode.
>> I see three layers in Solr:
>>
>>1. Lucene (the actual search libraries)
>>2. The server infra ("standalone Solr" basically)
>>3. Cluster management (SolrCloud)
>>
>> There's value in using lower layers without higher ones.
>> SolrCloud is a good solution for some use cases but there are others that
>> need a search server and for which SolrCloud is not a good fit and will
>> likely never be. If standalone mode is no longer available, such use cases
>> will have to turn to something other than Solr (or fork and go their own
>> way).
>>
>> Ilan
>>
>> On Sat, Jun 27, 2020 at 9:39 PM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>> > Rather than getting rid of the terminology, we should get rid of the
>> > standalone mode Solr altogether. I totally understand that SolrCloud is
>> > broken in many ways today, but we should attempt to fix it and have it
>> as
>> > the only mode in Solr.
>> >
>> > On Wed, 24 Jun, 2020, 8:17 pm Mike Drob,  wrote:
>> >
>> > > Brend,
>> > >
>> > > I appreciate that you are trying to examine this issue from multiple
>> > sides
>> > > and consider future implications, but I don’t think that is a stirring
>> > > argument. By analogy, if we are out of eggs and my wife asks me to go
>> to
>> > > the store to get some, refusing to do so on the basis that she might
>> call
>> > > me while I’m there and also ask me to get milk would not be
>> reasonable.
>> > >
>> > > What will come next may be an interesting question philosophically,
>> but
>> > we
>> > > are not discussing abstract concepts here. There is a concrete issue
>> > > identified, and we’re soliciting input in how best to address it.
>> > >
>> > > Thank you for the suggestion of "guide/follower"
>> > >
>> > > Mike
>> > >
>> > > On Wed, Jun 24, 2020 at 6:30 AM Bernd Fehling <
>> > > bernd.fehl...@uni-bielefeld.de> wrote:
>> > >
>> > > > I'm following this thread now for a while and I can understand
>> > > > the wish to change some naming/wording/speech in one or the other
>> > > > programs but I always get back to the one question:
>> > > > "Is it the weapon which kills people or the hand controlled by
>> > > > the mind which fires the weapon?"
>> > > >
>> > > > The thread started with slave - slavery, then turned over to master
>> > > > and followed by leader (for me as a german... you know).
>> > > > What will come next?
>> > > >
>> > > > And more over, we now discuss about changes in the source code and
>> > > > due to this there need to be changes to the documentation.
>> > > > What about the books people wrote about this programs and source
>> code,
>> > > > should we force this authors to rewrite their books?
>> > > > May be we should file a request to all web search engines to reject
>> > > > all stored content about these "banned" words?
>> > > > And contact all web hosters about providing bad content.
>> > > >
>> > > > To sum things up, within my 40 years of computer science and writing
>> > > > programs I have never had a nanosecond any thoughts about words
>> > > > like master, slave, leader, ... other than thinking about computers
>> > > > and programming.
>> > > >
>> > > > Just my 2 cents.
>> > > >
>> > > > For what it is worth, I tend to guide/follower if there "must be"
>> any
>> > > > changes.
>> > > >
>> > > > Bernd
>> > > >
>> > >
>> >
>>
>

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Ishan Chattopadhyaya]

I would like to know under which situations (except for the various bugs
that will be fixed eventually) would a SolrCloud solution not suffice.
AFAICT, pull replicas and tlog replicas can provide similar replication
strategies commonly used with standalone Solr. I understand that running ZK
is an overhead and SolrCloud isn't best written when it comes to handling
ZK, but that can be improved.

And for those users who just want a single node Solr, they can just start
Solr with embedded ZK. It won't practically make difference.

On Sun, 28 Jun, 2020, 3:45 pm Ilan Ginzburg,  wrote:

> I disagree Ishan. We shouldn't get rid of standalone mode.
> I see three layers in Solr:
>
>1. Lucene (the actual search libraries)
>2. The server infra ("standalone Solr" basically)
>3. Cluster management (SolrCloud)
>
> There's value in using lower layers without higher ones.
> SolrCloud is a good solution for some use cases but there are others that
> need a search server and for which SolrCloud is not a good fit and will
> likely never be. If standalone mode is no longer available, such use cases
> will have to turn to something other than Solr (or fork and go their own
> way).
>
> Ilan
>
> On Sat, Jun 27, 2020 at 9:39 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
> > Rather than getting rid of the terminology, we should get rid of the
> > standalone mode Solr altogether. I totally understand that SolrCloud is
> > broken in many ways today, but we should attempt to fix it and have it as
> > the only mode in Solr.
> >
> > On Wed, 24 Jun, 2020, 8:17 pm Mike Drob,  wrote:
> >
> > > Brend,
> > >
> > > I appreciate that you are trying to examine this issue from multiple
> > sides
> > > and consider future implications, but I don’t think that is a stirring
> > > argument. By analogy, if we are out of eggs and my wife asks me to go
> to
> > > the store to get some, refusing to do so on the basis that she might
> call
> > > me while I’m there and also ask me to get milk would not be reasonable.
> > >
> > > What will come next may be an interesting question philosophically, but
> > we
> > > are not discussing abstract concepts here. There is a concrete issue
> > > identified, and we’re soliciting input in how best to address it.
> > >
> > > Thank you for the suggestion of "guide/follower"
> > >
> > > Mike
> > >
> > > On Wed, Jun 24, 2020 at 6:30 AM Bernd Fehling <
> > > bernd.fehl...@uni-bielefeld.de> wrote:
> > >
> > > > I'm following this thread now for a while and I can understand
> > > > the wish to change some naming/wording/speech in one or the other
> > > > programs but I always get back to the one question:
> > > > "Is it the weapon which kills people or the hand controlled by
> > > > the mind which fires the weapon?"
> > > >
> > > > The thread started with slave - slavery, then turned over to master
> > > > and followed by leader (for me as a german... you know).
> > > > What will come next?
> > > >
> > > > And more over, we now discuss about changes in the source code and
> > > > due to this there need to be changes to the documentation.
> > > > What about the books people wrote about this programs and source
> code,
> > > > should we force this authors to rewrite their books?
> > > > May be we should file a request to all web search engines to reject
> > > > all stored content about these "banned" words?
> > > > And contact all web hosters about providing bad content.
> > > >
> > > > To sum things up, within my 40 years of computer science and writing
> > > > programs I have never had a nanosecond any thoughts about words
> > > > like master, slave, leader, ... other than thinking about computers
> > > > and programming.
> > > >
> > > > Just my 2 cents.
> > > >
> > > > For what it is worth, I tend to guide/follower if there "must be" any
> > > > changes.
> > > >
> > > > Bernd
> > > >
> > >
> >
>

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Ilan Ginzburg]

I disagree Ishan. We shouldn't get rid of standalone mode.
I see three layers in Solr:

   1. Lucene (the actual search libraries)
   2. The server infra ("standalone Solr" basically)
   3. Cluster management (SolrCloud)

There's value in using lower layers without higher ones.
SolrCloud is a good solution for some use cases but there are others that
need a search server and for which SolrCloud is not a good fit and will
likely never be. If standalone mode is no longer available, such use cases
will have to turn to something other than Solr (or fork and go their own
way).

Ilan

On Sat, Jun 27, 2020 at 9:39 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Rather than getting rid of the terminology, we should get rid of the
> standalone mode Solr altogether. I totally understand that SolrCloud is
> broken in many ways today, but we should attempt to fix it and have it as
> the only mode in Solr.
>
> On Wed, 24 Jun, 2020, 8:17 pm Mike Drob,  wrote:
>
> > Brend,
> >
> > I appreciate that you are trying to examine this issue from multiple
> sides
> > and consider future implications, but I don’t think that is a stirring
> > argument. By analogy, if we are out of eggs and my wife asks me to go to
> > the store to get some, refusing to do so on the basis that she might call
> > me while I’m there and also ask me to get milk would not be reasonable.
> >
> > What will come next may be an interesting question philosophically, but
> we
> > are not discussing abstract concepts here. There is a concrete issue
> > identified, and we’re soliciting input in how best to address it.
> >
> > Thank you for the suggestion of "guide/follower"
> >
> > Mike
> >
> > On Wed, Jun 24, 2020 at 6:30 AM Bernd Fehling <
> > bernd.fehl...@uni-bielefeld.de> wrote:
> >
> > > I'm following this thread now for a while and I can understand
> > > the wish to change some naming/wording/speech in one or the other
> > > programs but I always get back to the one question:
> > > "Is it the weapon which kills people or the hand controlled by
> > > the mind which fires the weapon?"
> > >
> > > The thread started with slave - slavery, then turned over to master
> > > and followed by leader (for me as a german... you know).
> > > What will come next?
> > >
> > > And more over, we now discuss about changes in the source code and
> > > due to this there need to be changes to the documentation.
> > > What about the books people wrote about this programs and source code,
> > > should we force this authors to rewrite their books?
> > > May be we should file a request to all web search engines to reject
> > > all stored content about these "banned" words?
> > > And contact all web hosters about providing bad content.
> > >
> > > To sum things up, within my 40 years of computer science and writing
> > > programs I have never had a nanosecond any thoughts about words
> > > like master, slave, leader, ... other than thinking about computers
> > > and programming.
> > >
> > > Just my 2 cents.
> > >
> > > For what it is worth, I tend to guide/follower if there "must be" any
> > > changes.
> > >
> > > Bernd
> > >
> >
>

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Ishan Chattopadhyaya]

Rather than getting rid of the terminology, we should get rid of the
standalone mode Solr altogether. I totally understand that SolrCloud is
broken in many ways today, but we should attempt to fix it and have it as
the only mode in Solr.

On Wed, 24 Jun, 2020, 8:17 pm Mike Drob,  wrote:

> Brend,
>
> I appreciate that you are trying to examine this issue from multiple sides
> and consider future implications, but I don’t think that is a stirring
> argument. By analogy, if we are out of eggs and my wife asks me to go to
> the store to get some, refusing to do so on the basis that she might call
> me while I’m there and also ask me to get milk would not be reasonable.
>
> What will come next may be an interesting question philosophically, but we
> are not discussing abstract concepts here. There is a concrete issue
> identified, and we’re soliciting input in how best to address it.
>
> Thank you for the suggestion of "guide/follower"
>
> Mike
>
> On Wed, Jun 24, 2020 at 6:30 AM Bernd Fehling <
> bernd.fehl...@uni-bielefeld.de> wrote:
>
> > I'm following this thread now for a while and I can understand
> > the wish to change some naming/wording/speech in one or the other
> > programs but I always get back to the one question:
> > "Is it the weapon which kills people or the hand controlled by
> > the mind which fires the weapon?"
> >
> > The thread started with slave - slavery, then turned over to master
> > and followed by leader (for me as a german... you know).
> > What will come next?
> >
> > And more over, we now discuss about changes in the source code and
> > due to this there need to be changes to the documentation.
> > What about the books people wrote about this programs and source code,
> > should we force this authors to rewrite their books?
> > May be we should file a request to all web search engines to reject
> > all stored content about these "banned" words?
> > And contact all web hosters about providing bad content.
> >
> > To sum things up, within my 40 years of computer science and writing
> > programs I have never had a nanosecond any thoughts about words
> > like master, slave, leader, ... other than thinking about computers
> > and programming.
> >
> > Just my 2 cents.
> >
> > For what it is worth, I tend to guide/follower if there "must be" any
> > changes.
> >
> > Bernd
> >
>

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Mike Drob]

Brend,

I appreciate that you are trying to examine this issue from multiple sides
and consider future implications, but I don’t think that is a stirring
argument. By analogy, if we are out of eggs and my wife asks me to go to
the store to get some, refusing to do so on the basis that she might call
me while I’m there and also ask me to get milk would not be reasonable.

What will come next may be an interesting question philosophically, but we
are not discussing abstract concepts here. There is a concrete issue
identified, and we’re soliciting input in how best to address it.

Thank you for the suggestion of "guide/follower"

Mike

On Wed, Jun 24, 2020 at 6:30 AM Bernd Fehling <
bernd.fehl...@uni-bielefeld.de> wrote:

> I'm following this thread now for a while and I can understand
> the wish to change some naming/wording/speech in one or the other
> programs but I always get back to the one question:
> "Is it the weapon which kills people or the hand controlled by
> the mind which fires the weapon?"
>
> The thread started with slave - slavery, then turned over to master
> and followed by leader (for me as a german... you know).
> What will come next?
>
> And more over, we now discuss about changes in the source code and
> due to this there need to be changes to the documentation.
> What about the books people wrote about this programs and source code,
> should we force this authors to rewrite their books?
> May be we should file a request to all web search engines to reject
> all stored content about these "banned" words?
> And contact all web hosters about providing bad content.
>
> To sum things up, within my 40 years of computer science and writing
> programs I have never had a nanosecond any thoughts about words
> like master, slave, leader, ... other than thinking about computers
> and programming.
>
> Just my 2 cents.
>
> For what it is worth, I tend to guide/follower if there "must be" any
> changes.
>
> Bernd
>

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Emir Arnautović]

Hi all,
Here is how I see it and explain to others that are not too familiar with Solr: 
Solr comes in two flavours - Cloud and Standalone. In any mode Solr writes to 
primary core(s). There is option to have different types of replicas, but in 
Standalone mode one can only have pull replica. In addition to different types 
of replicas, in SolrCloud mode multiple cores can be shards of a singe 
collection and primary is not fixed.

Emir
--
Monitoring - Log Management - Alerting - Anomaly Detection
Solr & Elasticsearch Consulting Support Training - http://sematext.com/



> On 24 Jun 2020, at 15:19, Mark H. Wood  wrote:
> 
> On Wed, Jun 24, 2020 at 12:45:25PM +0200, Jan Høydahl wrote:
>> Master/slave and standalone are used interchangably to mean zk-less Solr. I 
>> have a feeling that master/slave is the more popular of the two, but 
>> personally I have been using both.
> 
> I've been trying to stay quiet and let the new-terminology issue
> settle, but I had a thought.  Someone has already pointed out that the
> so-called master/slave cluster is misnamed:  the so-called "master"
> node doesn't order the "slaves" about and indeed has no notion of
> being a master in any sense.  It acts as a servant to the "slave"
> nodes, which are in charge of keeping themselves updated.
> 
> So, it's kind of odd, but I could get used to calling this mode a
> "client/server cluster".
> 
> That leaves the question of what to call Solr Cloud mode, in which no
> node is permanently special.  I could see calling it a "herd" or
> suchlike.
> 
> Now I'll try to shut up again. :-)
> 
> -- 
> Mark H. Wood
> Lead Technology Analyst
> 
> University Library
> Indiana University - Purdue University Indianapolis
> 755 W. Michigan Street
> Indianapolis, IN 46202
> 317-274-0749
> www.ulib.iupui.edu

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Mark H. Wood]

On Wed, Jun 24, 2020 at 12:45:25PM +0200, Jan Høydahl wrote:
> Master/slave and standalone are used interchangably to mean zk-less Solr. I 
> have a feeling that master/slave is the more popular of the two, but 
> personally I have been using both.

I've been trying to stay quiet and let the new-terminology issue
settle, but I had a thought.  Someone has already pointed out that the
so-called master/slave cluster is misnamed:  the so-called "master"
node doesn't order the "slaves" about and indeed has no notion of
being a master in any sense.  It acts as a servant to the "slave"
nodes, which are in charge of keeping themselves updated.

So, it's kind of odd, but I could get used to calling this mode a
"client/server cluster".

That leaves the question of what to call Solr Cloud mode, in which no
node is permanently special.  I could see calling it a "herd" or
suchlike.

Now I'll try to shut up again. :-)

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Jörn Franke]

I agree with Bernd. I believe also that change is natural so eventually one 
needs to evolve the terminology or create a complete new product. To evolve the 
terminology one can write a page in the ref guide for translating it and over 
time adapt it in Solr etc.


> Am 24.06.2020 um 13:30 schrieb Bernd Fehling :
> 
> I'm following this thread now for a while and I can understand
> the wish to change some naming/wording/speech in one or the other
> programs but I always get back to the one question:
> "Is it the weapon which kills people or the hand controlled by
> the mind which fires the weapon?"
> 
> The thread started with slave - slavery, then turned over to master
> and followed by leader (for me as a german... you know).
> What will come next?
> 
> And more over, we now discuss about changes in the source code and
> due to this there need to be changes to the documentation.
> What about the books people wrote about this programs and source code,
> should we force this authors to rewrite their books?
> May be we should file a request to all web search engines to reject
> all stored content about these "banned" words?
> And contact all web hosters about providing bad content.
> 
> To sum things up, within my 40 years of computer science and writing
> programs I have never had a nanosecond any thoughts about words
> like master, slave, leader, ... other than thinking about computers
> and programming.
> 
> Just my 2 cents.
> 
> For what it is worth, I tend to guide/follower if there "must be" any changes.
> 
> Bernd

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Bernd Fehling]

I'm following this thread now for a while and I can understand
the wish to change some naming/wording/speech in one or the other
programs but I always get back to the one question:
"Is it the weapon which kills people or the hand controlled by
the mind which fires the weapon?"

The thread started with slave - slavery, then turned over to master
and followed by leader (for me as a german... you know).
What will come next?

And more over, we now discuss about changes in the source code and
due to this there need to be changes to the documentation.
What about the books people wrote about this programs and source code,
should we force this authors to rewrite their books?
May be we should file a request to all web search engines to reject
all stored content about these "banned" words?
And contact all web hosters about providing bad content.

To sum things up, within my 40 years of computer science and writing
programs I have never had a nanosecond any thoughts about words
like master, slave, leader, ... other than thinking about computers
and programming.

Just my 2 cents.

For what it is worth, I tend to guide/follower if there "must be" any changes.

Bernd

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Jan Høydahl]

Master/slave and standalone are used interchangably to mean zk-less Solr. I 
have a feeling that master/slave is the more popular of the two, but personally 
I have been using both.

Jan

> 24. jun. 2020 kl. 06:34 skrev Noble Paul :
> 
> Do we even call it the master/slave mode? I thought we had 2 modes
> 
> * Standalone mode
> * SolrCloud mode
> 
> On Wed, Jun 24, 2020 at 3:00 AM Tomás Fernández Löbbe
>  wrote:
>> 
>> I agree in general with what Trey and Jan said and have suggested. I
>> personally like to use "leader/follower". It's true that somewhat collides
>> with SolrCloud terminology, but that's not a problem IMO, now that replica
>> types exist, the “role” of the replica (leader vs. non-leader/follower)
>> doesn’t specify the internals of how they behave, the replica type defines
>> that. So, in a non-SolrCloud world, they would still be leader/followers
>> regardless of how they perform that role.
>> 
>> I also agree that the name of the role is not that important, more the
>> "mode" of the architecture needs to be renamed. We tend to refer to
>> "SolrCloud mode" and "Master/Slave mode", the main part in all this (IMO)
>> is to change that "mode" name. I kind of like Trey's suggestion of "Managed
>> Clustering" vs. "Manual Clustering" Mode (Or "managed" vs "manual"), but
>> still haven't made up my mind (especially the fact that "manual" usually
>> doesn't really mean "manual", is just "you build your tools”)…
>> 
>> On Fri, Jun 19, 2020 at 1:38 PM Walter Underwood 
>> wrote:
>> 
 On Jun 19, 2020, at 7:48 AM, Phill Campbell
>>>  wrote:
 
 Delegator - Handler
 
 A common pattern we are all aware of. Pretty simple.
>>> 
>>> The Solr master does not delegate and the slave does not handle.
>>> The master is a server that handles replication requests from the
>>> slave.
>>> 
>>> Delegator/handler is a common pattern, but it is not the pattern
>>> that describes traditional Solr replication.
>>> 
>>> wunder
>>> Walter Underwood
>>> wun...@wunderwood.org
>>> http://observer.wunderwood.org/  (my blog)
>>> 
>>> 
> 
> 
> 
> -- 
> -
> Noble Paul

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Paras Lehana]

Distributer/Fetcher?

On Wed, 24 Jun 2020 at 10:04, Noble Paul  wrote:

> Do we even call it the master/slave mode? I thought we had 2 modes
>
> * Standalone mode
> * SolrCloud mode
>
> On Wed, Jun 24, 2020 at 3:00 AM Tomás Fernández Löbbe
>  wrote:
> >
> > I agree in general with what Trey and Jan said and have suggested. I
> > personally like to use "leader/follower". It's true that somewhat
> collides
> > with SolrCloud terminology, but that's not a problem IMO, now that
> replica
> > types exist, the “role” of the replica (leader vs. non-leader/follower)
> > doesn’t specify the internals of how they behave, the replica type
> defines
> > that. So, in a non-SolrCloud world, they would still be leader/followers
> > regardless of how they perform that role.
> >
> > I also agree that the name of the role is not that important, more the
> > "mode" of the architecture needs to be renamed. We tend to refer to
> > "SolrCloud mode" and "Master/Slave mode", the main part in all this (IMO)
> > is to change that "mode" name. I kind of like Trey's suggestion of
> "Managed
> > Clustering" vs. "Manual Clustering" Mode (Or "managed" vs "manual"), but
> > still haven't made up my mind (especially the fact that "manual" usually
> > doesn't really mean "manual", is just "you build your tools”)…
> >
> > On Fri, Jun 19, 2020 at 1:38 PM Walter Underwood 
> > wrote:
> >
> > > > On Jun 19, 2020, at 7:48 AM, Phill Campbell
> > >  wrote:
> > > >
> > > > Delegator - Handler
> > > >
> > > > A common pattern we are all aware of. Pretty simple.
> > >
> > > The Solr master does not delegate and the slave does not handle.
> > > The master is a server that handles replication requests from the
> > > slave.
> > >
> > > Delegator/handler is a common pattern, but it is not the pattern
> > > that describes traditional Solr replication.
> > >
> > > wunder
> > > Walter Underwood
> > > wun...@wunderwood.org
> > > http://observer.wunderwood.org/  (my blog)
> > >
> > >
>
>
>
> --
> -
> Noble Paul
>


-- 
-- 
Regards,

*Paras Lehana* [65871]
Development Engineer, *Auto-Suggest*,
IndiaMART InterMESH Ltd,

11th Floor, Tower 2, Assotech Business Cresterra,
Plot No. 22, Sector 135, Noida, Uttar Pradesh, India 201305

Mob.: +91-9560911996
Work: 0120-4056700 | Extn:
*1196*

-- 
*
*

 

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Noble Paul]

Do we even call it the master/slave mode? I thought we had 2 modes

* Standalone mode
* SolrCloud mode

On Wed, Jun 24, 2020 at 3:00 AM Tomás Fernández Löbbe
 wrote:
>
> I agree in general with what Trey and Jan said and have suggested. I
> personally like to use "leader/follower". It's true that somewhat collides
> with SolrCloud terminology, but that's not a problem IMO, now that replica
> types exist, the “role” of the replica (leader vs. non-leader/follower)
> doesn’t specify the internals of how they behave, the replica type defines
> that. So, in a non-SolrCloud world, they would still be leader/followers
> regardless of how they perform that role.
>
> I also agree that the name of the role is not that important, more the
> "mode" of the architecture needs to be renamed. We tend to refer to
> "SolrCloud mode" and "Master/Slave mode", the main part in all this (IMO)
> is to change that "mode" name. I kind of like Trey's suggestion of "Managed
> Clustering" vs. "Manual Clustering" Mode (Or "managed" vs "manual"), but
> still haven't made up my mind (especially the fact that "manual" usually
> doesn't really mean "manual", is just "you build your tools”)…
>
> On Fri, Jun 19, 2020 at 1:38 PM Walter Underwood 
> wrote:
>
> > > On Jun 19, 2020, at 7:48 AM, Phill Campbell
> >  wrote:
> > >
> > > Delegator - Handler
> > >
> > > A common pattern we are all aware of. Pretty simple.
> >
> > The Solr master does not delegate and the slave does not handle.
> > The master is a server that handles replication requests from the
> > slave.
> >
> > Delegator/handler is a common pattern, but it is not the pattern
> > that describes traditional Solr replication.
> >
> > wunder
> > Walter Underwood
> > wun...@wunderwood.org
> > http://observer.wunderwood.org/  (my blog)
> >
> >



-- 
-
Noble Paul

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Tomás Fernández Löbbe]

I agree in general with what Trey and Jan said and have suggested. I
personally like to use "leader/follower". It's true that somewhat collides
with SolrCloud terminology, but that's not a problem IMO, now that replica
types exist, the “role” of the replica (leader vs. non-leader/follower)
doesn’t specify the internals of how they behave, the replica type defines
that. So, in a non-SolrCloud world, they would still be leader/followers
regardless of how they perform that role.

I also agree that the name of the role is not that important, more the
"mode" of the architecture needs to be renamed. We tend to refer to
"SolrCloud mode" and "Master/Slave mode", the main part in all this (IMO)
is to change that "mode" name. I kind of like Trey's suggestion of "Managed
Clustering" vs. "Manual Clustering" Mode (Or "managed" vs "manual"), but
still haven't made up my mind (especially the fact that "manual" usually
doesn't really mean "manual", is just "you build your tools”)…

On Fri, Jun 19, 2020 at 1:38 PM Walter Underwood 
wrote:

> > On Jun 19, 2020, at 7:48 AM, Phill Campbell
>  wrote:
> >
> > Delegator - Handler
> >
> > A common pattern we are all aware of. Pretty simple.
>
> The Solr master does not delegate and the slave does not handle.
> The master is a server that handles replication requests from the
> slave.
>
> Delegator/handler is a common pattern, but it is not the pattern
> that describes traditional Solr replication.
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
>

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Walter Underwood]

> On Jun 19, 2020, at 7:48 AM, Phill Campbell  
> wrote:
> 
> Delegator - Handler
> 
> A common pattern we are all aware of. Pretty simple.

The Solr master does not delegate and the slave does not handle.
The master is a server that handles replication requests from the
slave.

Delegator/handler is a common pattern, but it is not the pattern
that describes traditional Solr replication.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Jörn Franke]

Might be confusing with the nested doc terminology 

> Am 19.06.2020 um 20:14 schrieb Atita Arora :
> 
> I see so many topics being discussed in this thread and I literary got lost
> somewhere , but was just thinking can we call it Parent -Child
> architecture, m sure no one will raise an objection there.
> 
> Although, looking at comments above I still feel it would be a bigger
> effort to convince everyone than making a change. ;)
> 
>> On Fri, 19 Jun 2020, 17:21 Mark H. Wood,  wrote:
>> 
>>> On Fri, Jun 19, 2020 at 09:22:49AM -0400, j.s. wrote:
>>> On 6/18/20 9:50 PM, Rahul Goswami wrote:
 So +1 on "slave" being the problematic term IMO, not "master".
>>> 
>>> but you cannot have a master without a slave, n'est-ce pas?
>> 
>> Well, yes.  In education:  Master of Science, Arts, etc.  In law:
>> Special Master (basically a judge's delegate).  See also "magistrate."
>> None of these has any connotation of the ownership of one person by
>> another.
>> 
>> (It's a one-way relationship:  there is no slavery without mastery,
>> but there are other kinds of mastery.)
>> 
>> But this is an emotional issue, not a logical one.  If doing X makes
>> people angry, and we don't want to make those people angry, then
>> perhaps we should not do X.
>> 
>>> i think it is better to use the metaphor of copying rather than one of
>>> hierarchy. language has so many (unintended) consequences ...
>> 
>> Sensible.
>> 
>> --
>> Mark H. Wood
>> Lead Technology Analyst
>> 
>> University Library
>> Indiana University - Purdue University Indianapolis
>> 755 W. Michigan Street
>> Indianapolis, IN 46202
>> 317-274-0749
>> www.ulib.iupui.edu
>> 

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Atita Arora]

I see so many topics being discussed in this thread and I literary got lost
somewhere , but was just thinking can we call it Parent -Child
architecture, m sure no one will raise an objection there.

Although, looking at comments above I still feel it would be a bigger
effort to convince everyone than making a change. ;)

On Fri, 19 Jun 2020, 17:21 Mark H. Wood,  wrote:

> On Fri, Jun 19, 2020 at 09:22:49AM -0400, j.s. wrote:
> > On 6/18/20 9:50 PM, Rahul Goswami wrote:
> > > So +1 on "slave" being the problematic term IMO, not "master".
> >
> > but you cannot have a master without a slave, n'est-ce pas?
>
> Well, yes.  In education:  Master of Science, Arts, etc.  In law:
> Special Master (basically a judge's delegate).  See also "magistrate."
> None of these has any connotation of the ownership of one person by
> another.
>
> (It's a one-way relationship:  there is no slavery without mastery,
> but there are other kinds of mastery.)
>
> But this is an emotional issue, not a logical one.  If doing X makes
> people angry, and we don't want to make those people angry, then
> perhaps we should not do X.
>
> > i think it is better to use the metaphor of copying rather than one of
> > hierarchy. language has so many (unintended) consequences ...
>
> Sensible.
>
> --
> Mark H. Wood
> Lead Technology Analyst
>
> University Library
> Indiana University - Purdue University Indianapolis
> 755 W. Michigan Street
> Indianapolis, IN 46202
> 317-274-0749
> www.ulib.iupui.edu
>

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Mark H. Wood]

On Fri, Jun 19, 2020 at 09:22:49AM -0400, j.s. wrote:
> On 6/18/20 9:50 PM, Rahul Goswami wrote:
> > So +1 on "slave" being the problematic term IMO, not "master".
> 
> but you cannot have a master without a slave, n'est-ce pas?

Well, yes.  In education:  Master of Science, Arts, etc.  In law:
Special Master (basically a judge's delegate).  See also "magistrate."
None of these has any connotation of the ownership of one person by
another.

(It's a one-way relationship:  there is no slavery without mastery,
but there are other kinds of mastery.)

But this is an emotional issue, not a logical one.  If doing X makes
people angry, and we don't want to make those people angry, then
perhaps we should not do X.

> i think it is better to use the metaphor of copying rather than one of 
> hierarchy. language has so many (unintended) consequences ...

Sensible.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Phill Campbell]

The entire idea of removing a word out of our language is problematic.
There will have to be a lot of history books that detail the terrible 
conditions of peoples over recorded history changed, or removed.

I find the “F” word extremely offensive. I find references to Deity while 
cursing extremely offensive. It is my privilege to deal with offense for the 
sake of liberty.

The use of the word is not promoting the practice nor is it denigrating those 
that have that in their history.

The “world” has decided, what ever.

Delegator - Handler

A common pattern we are all aware of. Pretty simple.



> On Jun 19, 2020, at 8:21 AM, Ilan Ginzburg  wrote:
> 
> +1 to Jan's "clustered" vs "non clustered".
> 
> If we clean up terminology, I suggest we also clarify the meaning and use
> of Slice vs Shard vs Leader vs Replica vs Core. Here's my understanding:
> 
> I consider Slice == Shard (and would happily drop Slice): a logical concept
> of a specific subset of a collection.
> A Shard then has one or multiple copies of the data called Replicas (if a
> shard has no copy of the data there's an issue). The Leader is one such
> Replica. A shard with a replication factor of 1 has a single Replica that
> happens to be the Leader. "Replica" does therefore not imply "replication".
> A Core is an in memory instantiation of a disk index representing a
> Replica. I believe that often the on disk index is referred to as "Core" as
> well (I'm not bothered by this, there's no associated confusion IMO).
> 
> Overseer is a central place where a fair bit of the cluster management
> logic is implemented today (Collection API, Autoscaling, Cluster state
> change). It is therefore a cluster manager. Note that a different
> implementation of "Clustered Solr" (a.k.a. SolrCloud) can most likely be
> done without the need of a central process in addition to the already
> centralized storage backend (currently ZooKeeper). In other words, Overseer
> is not IMO the defining characteristic of SolrCloud, it is one
> implementation choice, and there are others. To keep in mind for clarity
> and to guide renaming.
> 
> On Fri, Jun 19, 2020 at 3:23 PM j.s.  wrote:
> 
>> hi
>> 
>> solr is very helpful.
>> 
>> On 6/18/20 9:50 PM, Rahul Goswami wrote:
>>> So +1 on "slave" being the problematic term IMO, not "master".
>> 
>> but you cannot have a master without a slave, n'est-ce pas?
>> 
>> i think it is better to use the metaphor of copying rather than one of
>> hierarchy. language has so many (unintended) consequences ...
>> 
>> good luck!
>> 

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Ilan Ginzburg]

+1 to Jan's "clustered" vs "non clustered".

If we clean up terminology, I suggest we also clarify the meaning and use
of Slice vs Shard vs Leader vs Replica vs Core. Here's my understanding:

I consider Slice == Shard (and would happily drop Slice): a logical concept
of a specific subset of a collection.
A Shard then has one or multiple copies of the data called Replicas (if a
shard has no copy of the data there's an issue). The Leader is one such
Replica. A shard with a replication factor of 1 has a single Replica that
happens to be the Leader. "Replica" does therefore not imply "replication".
A Core is an in memory instantiation of a disk index representing a
Replica. I believe that often the on disk index is referred to as "Core" as
well (I'm not bothered by this, there's no associated confusion IMO).

Overseer is a central place where a fair bit of the cluster management
logic is implemented today (Collection API, Autoscaling, Cluster state
change). It is therefore a cluster manager. Note that a different
implementation of "Clustered Solr" (a.k.a. SolrCloud) can most likely be
done without the need of a central process in addition to the already
centralized storage backend (currently ZooKeeper). In other words, Overseer
is not IMO the defining characteristic of SolrCloud, it is one
implementation choice, and there are others. To keep in mind for clarity
and to guide renaming.

On Fri, Jun 19, 2020 at 3:23 PM j.s.  wrote:

> hi
>
> solr is very helpful.
>
> On 6/18/20 9:50 PM, Rahul Goswami wrote:
> > So +1 on "slave" being the problematic term IMO, not "master".
>
> but you cannot have a master without a slave, n'est-ce pas?
>
> i think it is better to use the metaphor of copying rather than one of
> hierarchy. language has so many (unintended) consequences ...
>
> good luck!
>

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[j.s.]

hi

solr is very helpful.

On 6/18/20 9:50 PM, Rahul Goswami wrote:

So +1 on "slave" being the problematic term IMO, not "master".


but you cannot have a master without a slave, n'est-ce pas?

i think it is better to use the metaphor of copying rather than one of 
hierarchy. language has so many (unintended) consequences ...


good luck!

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Jan Høydahl]

t;>>> While on the topic of renaming roles, I'd like to propose finding a
>> better
>>>> term than "overseer" which has historical slavery connotations as well.
>>>> Director, perhaps?
>>>> 
>>>> 
>>>> John Gallagher
>>>> 
>>>> On Thu, Jun 18, 2020 at 8:48 AM Jason Gerlowski 
>>>> wrote:
>>>> 
>>>>> +1 to rename master/slave, and +1 to choosing terminology distinct
>>>>> from what's used for SolrCloud.  I could be happy with several of the
>>>>> proposed options.  Since a good few have been proposed though, maybe
>>>>> an eventual vote thread is the most organized way to aggregate the
>>>>> opinions here.
>>>>> 
>>>>> I'm less positive about the prospect of changing the name of our
>>>>> primary git branch.  Most projects that contributors might come from,
>>>>> most tutorials out there to learn git, most tools built on top of git
>>>>> - the majority are going to assume "master" as the main branch.  I
>>>>> appreciate the change that Github is trying to effect in changing the
>>>>> default for new projects, but it'll be a long time before that
>>>>> competes with the huge bulk of projects, documentation, etc. out there
>>>>> using "master".  Our contributors are smart and I'm sure they'd figure
>>>>> it out if we used "main" or something else instead, but having a
>>>>> non-standard git setup would be one more "papercut" in understanding
>>>>> how to contribute to a project that already makes that harder than it
>>>>> should.
>>>>> 
>>>>> Jason
>>>>> 
>>>>> 
>>>>> On Thu, Jun 18, 2020 at 7:33 AM Demian Katz >> 
>>>>> wrote:
>>>>>> 
>>>>>> Regarding people having a problem with the word "master" -- GitHub is
>>>>> changing the default branch name away from "master," even in isolation
>>>> from
>>>>> a "slave" pairing... so the terminology seems to be falling out of
>> favor
>>>> in
>>>>> all contexts. See:
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> https://www.cnet.com/news/microsofts-github-is-removing-coding-terms-like-master-and-slave/
>>>>>> 
>>>>>> I'm not here to start a debate about the semantics of that, just to
>>>>> provide evidence that in some communities, the term "master" is causing
>>>>> concern all by itself. If we're going to make the change anyway, it
>> might
>>>>> be best to get it over with and pick the most appropriate terminology
>> we
>>>>> can agree upon, rather than trying to minimize the amount of change.
>> It's
>>>>> going to be backward breaking anyway, so we might as well do it all now
>>>>> rather than risk having to go through two separate breaking changes at
>>>>> different points in time.
>>>>>> 
>>>>>> - Demian
>>>>>> 
>>>>>> -Original Message-
>>>>>> From: Noble Paul 
>>>>>> Sent: Thursday, June 18, 2020 1:51 AM
>>>>>> To: solr-user@lucene.apache.org
>>>>>> Subject: [EXTERNAL] Re: Getting rid of Master/Slave nomenclature in
>>>> Solr
>>>>>> 
>>>>>> Looking at the code I see a 692 occurrences of the word "slave".
>>>>>> Mostly variable names and ref guide docs.
>>>>>> 
>>>>>> The word "slave" is present in the responses as well. Any change in
>> the
>>>>> request param/response payload is backward incompatible.
>>>>>> 
>>>>>> I have no objection to changing the names in ref guide and other
>>>>> internal variables. Going ahead with backward incompatible changes is
>>>>> painful. If somebody has the appetite to take it up, it's OK
>>>>>> 
>>>>>> If we must change, master/follower can be a good enough option.
>>>>>> 
>>>>>> master (noun): A man in charge of an organization or group.
>>>>>> master(adj) : having or showing very great skill or proficiency.
>>>>>> master(verb): acquire complete knowledge or skill in (a subject,
>>>>> technique, or art).
>>>>>> master (verb): gain control of; overcome.
>>>>>> 
>>>>>> I hope nobody has a problem with the term "master"
>>>>>> 
>>>>>> On Thu, Jun 18, 2020 at 3:19 PM Ilan Ginzburg 
>>>>> wrote:
>>>>>>> 
>>>>>>> Would master/follower work?
>>>>>>> 
>>>>>>> Half the rename work while still getting rid of the slavery
>>>>> connotation...
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu 18 Jun 2020 at 07:13, Walter Underwood >>>> 
>>>>> wrote:
>>>>>>> 
>>>>>>>>> On Jun 17, 2020, at 4:00 PM, Shawn Heisey 
>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> It has been interesting watching this discussion play out on
>>>>>>>>> multiple
>>>>>>>> open source mailing lists.  On other projects, I have seen a VERY
>>>>>>>> high level of resistance to these changes, which I find disturbing
>>>>>>>> and surprising.
>>>>>>>> 
>>>>>>>> Yes, it is nice to see everyone just pitch in and do it on this
>>>> list.
>>>>>>>> 
>>>>>>>> wunder
>>>>>>>> Walter Underwood
>>>>>>>> wun...@wunderwood.org
>>>>>>>> 
>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fobs
>>>>>>>> erver.wunderwood.org
>>>> %2Fdata=02%7C01%7Cdemian.katz%40villanova.e
>>>>>>>> 
>>>> du%7C1eef0604700a442deb7e08d8134b97fb%7C765a8de5cf9444f09cafae5bf8cf
>>>>>>>> 
>>>> a366%7C0%7C0%7C637280562684672329sdata=0GyK5Tlq0PGsWxl%2FirJOVN
>>>>>>>> VaFCELlEChdxuLJ5RxdQs%3Dreserved=0  (my blog)
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> -
>>>>>> Noble Paul
>>>>> 
>>>> 
>> 
>> 

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[gnandre]

gt;> > >> have
>> > >>>> less Solr experience than we do and are less familiar with the
>> > >> intricacies.
>> > >>>>
>> > >>>> Primary/Replica seems acceptable. Coordinator instead of Overseer
>> > seems
>> > >>>> acceptable.
>> > >>>>
>> > >>>> Would love to see this in 9.0!
>> > >>>>
>> > >>>> Mike
>> > >>>>
>> > >>>> On Thu, Jun 18, 2020 at 8:25 AM John Gallagher
>> > >>>>  wrote:
>> > >>>>
>> > >>>>> While on the topic of renaming roles, I'd like to propose finding
>> a
>> > >> better
>> > >>>>> term than "overseer" which has historical slavery connotations as
>> > well.
>> > >>>>> Director, perhaps?
>> > >>>>>
>> > >>>>>
>> > >>>>> John Gallagher
>> > >>>>>
>> > >>>>> On Thu, Jun 18, 2020 at 8:48 AM Jason Gerlowski <
>> > gerlowsk...@gmail.com
>> > >>>
>> > >>>>> wrote:
>> > >>>>>
>> > >>>>>> +1 to rename master/slave, and +1 to choosing terminology
>> distinct
>> > >>>>>> from what's used for SolrCloud.  I could be happy with several of
>> > the
>> > >>>>>> proposed options.  Since a good few have been proposed though,
>> maybe
>> > >>>>>> an eventual vote thread is the most organized way to aggregate
>> the
>> > >>>>>> opinions here.
>> > >>>>>>
>> > >>>>>> I'm less positive about the prospect of changing the name of our
>> > >>>>>> primary git branch.  Most projects that contributors might come
>> > from,
>> > >>>>>> most tutorials out there to learn git, most tools built on top of
>> > git
>> > >>>>>> - the majority are going to assume "master" as the main branch.
>> I
>> > >>>>>> appreciate the change that Github is trying to effect in changing
>> > the
>> > >>>>>> default for new projects, but it'll be a long time before that
>> > >>>>>> competes with the huge bulk of projects, documentation, etc. out
>> > there
>> > >>>>>> using "master".  Our contributors are smart and I'm sure they'd
>> > figure
>> > >>>>>> it out if we used "main" or something else instead, but having a
>> > >>>>>> non-standard git setup would be one more "papercut" in
>> understanding
>> > >>>>>> how to contribute to a project that already makes that harder
>> than
>> > it
>> > >>>>>> should.
>> > >>>>>>
>> > >>>>>> Jason
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> On Thu, Jun 18, 2020 at 7:33 AM Demian Katz <
>> > >> demian.k...@villanova.edu>
>> > >>>>>> wrote:
>> > >>>>>>>
>> > >>>>>>> Regarding people having a problem with the word "master" --
>> GitHub
>> > is
>> > >>>>>> changing the default branch name away from "master," even in
>> > isolation
>> > >>>>> from
>> > >>>>>> a "slave" pairing... so the terminology seems to be falling out
>> of
>> > >> favor
>> > >>>>> in
>> > >>>>>> all contexts. See:
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>
>> > >>>>>
>> > >>
>> >
>> https://www.cnet.com/news/microsofts-github-is-removing-coding-terms-like-master-and-slave/
>> > >>>>>>>
>> > >>>>>>> I'm not here to start a debate about the semantics of that,
>> just to
>> > >>>>>> provide evidence that in some communities, the term "master" is
>> > >> causing
>> > >>>>>> concern all by itself. If we're going to make the change anyw

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[gnandre]

;>
> > >>>>> While on the topic of renaming roles, I'd like to propose finding a
> > >> better
> > >>>>> term than "overseer" which has historical slavery connotations as
> > well.
> > >>>>> Director, perhaps?
> > >>>>>
> > >>>>>
> > >>>>> John Gallagher
> > >>>>>
> > >>>>> On Thu, Jun 18, 2020 at 8:48 AM Jason Gerlowski <
> > gerlowsk...@gmail.com
> > >>>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> +1 to rename master/slave, and +1 to choosing terminology distinct
> > >>>>>> from what's used for SolrCloud.  I could be happy with several of
> > the
> > >>>>>> proposed options.  Since a good few have been proposed though,
> maybe
> > >>>>>> an eventual vote thread is the most organized way to aggregate the
> > >>>>>> opinions here.
> > >>>>>>
> > >>>>>> I'm less positive about the prospect of changing the name of our
> > >>>>>> primary git branch.  Most projects that contributors might come
> > from,
> > >>>>>> most tutorials out there to learn git, most tools built on top of
> > git
> > >>>>>> - the majority are going to assume "master" as the main branch.  I
> > >>>>>> appreciate the change that Github is trying to effect in changing
> > the
> > >>>>>> default for new projects, but it'll be a long time before that
> > >>>>>> competes with the huge bulk of projects, documentation, etc. out
> > there
> > >>>>>> using "master".  Our contributors are smart and I'm sure they'd
> > figure
> > >>>>>> it out if we used "main" or something else instead, but having a
> > >>>>>> non-standard git setup would be one more "papercut" in
> understanding
> > >>>>>> how to contribute to a project that already makes that harder than
> > it
> > >>>>>> should.
> > >>>>>>
> > >>>>>> Jason
> > >>>>>>
> > >>>>>>
> > >>>>>> On Thu, Jun 18, 2020 at 7:33 AM Demian Katz <
> > >> demian.k...@villanova.edu>
> > >>>>>> wrote:
> > >>>>>>>
> > >>>>>>> Regarding people having a problem with the word "master" --
> GitHub
> > is
> > >>>>>> changing the default branch name away from "master," even in
> > isolation
> > >>>>> from
> > >>>>>> a "slave" pairing... so the terminology seems to be falling out of
> > >> favor
> > >>>>> in
> > >>>>>> all contexts. See:
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>
> >
> https://www.cnet.com/news/microsofts-github-is-removing-coding-terms-like-master-and-slave/
> > >>>>>>>
> > >>>>>>> I'm not here to start a debate about the semantics of that, just
> to
> > >>>>>> provide evidence that in some communities, the term "master" is
> > >> causing
> > >>>>>> concern all by itself. If we're going to make the change anyway,
> it
> > >> might
> > >>>>>> be best to get it over with and pick the most appropriate
> > terminology
> > >> we
> > >>>>>> can agree upon, rather than trying to minimize the amount of
> change.
> > >> It's
> > >>>>>> going to be backward breaking anyway, so we might as well do it
> all
> > >> now
> > >>>>>> rather than risk having to go through two separate breaking
> changes
> > at
> > >>>>>> different points in time.
> > >>>>>>>
> > >>>>>>> - Demian
> > >>>>>>>
> > >>>>>>> -Original Message-
> > >>>>>>> From: Noble Paul 
> > >>>>>>> Sent: Thursday, June 18, 2020 1:51 AM
> > >>>>>>> To: solr-user@lucene.apache.org
> > >>>>>>> Subject: [EXTERNAL] Re: Getting rid of Master/Slave nomenclature
> in
> > >>>>> Solr
> > >>>>>>>
> > >>>>>>> Looking at the code I see a 692 occurrences of the word "slave".
> > >>>>>>> Mostly variable names and ref guide docs.
> > >>>>>>>
> > >>>>>>> The word "slave" is present in the responses as well. Any change
> in
> > >> the
> > >>>>>> request param/response payload is backward incompatible.
> > >>>>>>>
> > >>>>>>> I have no objection to changing the names in ref guide and other
> > >>>>>> internal variables. Going ahead with backward incompatible changes
> > is
> > >>>>>> painful. If somebody has the appetite to take it up, it's OK
> > >>>>>>>
> > >>>>>>> If we must change, master/follower can be a good enough option.
> > >>>>>>>
> > >>>>>>> master (noun): A man in charge of an organization or group.
> > >>>>>>> master(adj) : having or showing very great skill or proficiency.
> > >>>>>>> master(verb): acquire complete knowledge or skill in (a subject,
> > >>>>>> technique, or art).
> > >>>>>>> master (verb): gain control of; overcome.
> > >>>>>>>
> > >>>>>>> I hope nobody has a problem with the term "master"
> > >>>>>>>
> > >>>>>>> On Thu, Jun 18, 2020 at 3:19 PM Ilan Ginzburg <
> ilans...@gmail.com>
> > >>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>> Would master/follower work?
> > >>>>>>>>
> > >>>>>>>> Half the rename work while still getting rid of the slavery
> > >>>>>> connotation...
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Thu 18 Jun 2020 at 07:13, Walter Underwood <
> > >> wun...@wunderwood.org
> > >>>>>>
> > >>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>>> On Jun 17, 2020, at 4:00 PM, Shawn Heisey <
> apa...@elyograg.org>
> > >>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>> It has been interesting watching this discussion play out on
> > >>>>>>>>>> multiple
> > >>>>>>>>> open source mailing lists.  On other projects, I have seen a
> VERY
> > >>>>>>>>> high level of resistance to these changes, which I find
> > disturbing
> > >>>>>>>>> and surprising.
> > >>>>>>>>>
> > >>>>>>>>> Yes, it is nice to see everyone just pitch in and do it on this
> > >>>>> list.
> > >>>>>>>>>
> > >>>>>>>>> wunder
> > >>>>>>>>> Walter Underwood
> > >>>>>>>>> wun...@wunderwood.org
> > >>>>>>>>>
> > >>>>>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fobs
> > >>>>>>>>> erver.wunderwood.org
> > >>>>> %2Fdata=02%7C01%7Cdemian.katz%40villanova.e
> > >>>>>>>>>
> > >>>>>
> du%7C1eef0604700a442deb7e08d8134b97fb%7C765a8de5cf9444f09cafae5bf8cf
> > >>>>>>>>>
> > >>>>>
> a366%7C0%7C0%7C637280562684672329sdata=0GyK5Tlq0PGsWxl%2FirJOVN
> > >>>>>>>>> VaFCELlEChdxuLJ5RxdQs%3Dreserved=0  (my blog)
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> -
> > >>>>>>> Noble Paul
> > >>>>>>
> > >>>>>
> > >>>
> > >>
> > >>
> >
> >
>

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Thomas Corthals]

>>>> from what's used for SolrCloud.  I could be happy with several of
> the
> >>>>>> proposed options.  Since a good few have been proposed though, maybe
> >>>>>> an eventual vote thread is the most organized way to aggregate the
> >>>>>> opinions here.
> >>>>>>
> >>>>>> I'm less positive about the prospect of changing the name of our
> >>>>>> primary git branch.  Most projects that contributors might come
> from,
> >>>>>> most tutorials out there to learn git, most tools built on top of
> git
> >>>>>> - the majority are going to assume "master" as the main branch.  I
> >>>>>> appreciate the change that Github is trying to effect in changing
> the
> >>>>>> default for new projects, but it'll be a long time before that
> >>>>>> competes with the huge bulk of projects, documentation, etc. out
> there
> >>>>>> using "master".  Our contributors are smart and I'm sure they'd
> figure
> >>>>>> it out if we used "main" or something else instead, but having a
> >>>>>> non-standard git setup would be one more "papercut" in understanding
> >>>>>> how to contribute to a project that already makes that harder than
> it
> >>>>>> should.
> >>>>>>
> >>>>>> Jason
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Jun 18, 2020 at 7:33 AM Demian Katz <
> >> demian.k...@villanova.edu>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Regarding people having a problem with the word "master" -- GitHub
> is
> >>>>>> changing the default branch name away from "master," even in
> isolation
> >>>>> from
> >>>>>> a "slave" pairing... so the terminology seems to be falling out of
> >> favor
> >>>>> in
> >>>>>> all contexts. See:
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>
> https://www.cnet.com/news/microsofts-github-is-removing-coding-terms-like-master-and-slave/
> >>>>>>>
> >>>>>>> I'm not here to start a debate about the semantics of that, just to
> >>>>>> provide evidence that in some communities, the term "master" is
> >> causing
> >>>>>> concern all by itself. If we're going to make the change anyway, it
> >> might
> >>>>>> be best to get it over with and pick the most appropriate
> terminology
> >> we
> >>>>>> can agree upon, rather than trying to minimize the amount of change.
> >> It's
> >>>>>> going to be backward breaking anyway, so we might as well do it all
> >> now
> >>>>>> rather than risk having to go through two separate breaking changes
> at
> >>>>>> different points in time.
> >>>>>>>
> >>>>>>> - Demian
> >>>>>>>
> >>>>>>> -Original Message-
> >>>>>>> From: Noble Paul 
> >>>>>>> Sent: Thursday, June 18, 2020 1:51 AM
> >>>>>>> To: solr-user@lucene.apache.org
> >>>>>>> Subject: [EXTERNAL] Re: Getting rid of Master/Slave nomenclature in
> >>>>> Solr
> >>>>>>>
> >>>>>>> Looking at the code I see a 692 occurrences of the word "slave".
> >>>>>>> Mostly variable names and ref guide docs.
> >>>>>>>
> >>>>>>> The word "slave" is present in the responses as well. Any change in
> >> the
> >>>>>> request param/response payload is backward incompatible.
> >>>>>>>
> >>>>>>> I have no objection to changing the names in ref guide and other
> >>>>>> internal variables. Going ahead with backward incompatible changes
> is
> >>>>>> painful. If somebody has the appetite to take it up, it's OK
> >>>>>>>
> >>>>>>> If we must change, master/follower can be a good enough option.
> >>>>>>>
> >>>>>>> master (noun): A man in charge of an organization or group.
> >>>>>>> master(adj) : having or showing very great skill or proficiency.
> >>>>>>> master(verb): acquire complete knowledge or skill in (a subject,
> >>>>>> technique, or art).
> >>>>>>> master (verb): gain control of; overcome.
> >>>>>>>
> >>>>>>> I hope nobody has a problem with the term "master"
> >>>>>>>
> >>>>>>> On Thu, Jun 18, 2020 at 3:19 PM Ilan Ginzburg 
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>> Would master/follower work?
> >>>>>>>>
> >>>>>>>> Half the rename work while still getting rid of the slavery
> >>>>>> connotation...
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Thu 18 Jun 2020 at 07:13, Walter Underwood <
> >> wun...@wunderwood.org
> >>>>>>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>>> On Jun 17, 2020, at 4:00 PM, Shawn Heisey 
> >>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> It has been interesting watching this discussion play out on
> >>>>>>>>>> multiple
> >>>>>>>>> open source mailing lists.  On other projects, I have seen a VERY
> >>>>>>>>> high level of resistance to these changes, which I find
> disturbing
> >>>>>>>>> and surprising.
> >>>>>>>>>
> >>>>>>>>> Yes, it is nice to see everyone just pitch in and do it on this
> >>>>> list.
> >>>>>>>>>
> >>>>>>>>> wunder
> >>>>>>>>> Walter Underwood
> >>>>>>>>> wun...@wunderwood.org
> >>>>>>>>>
> >>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fobs
> >>>>>>>>> erver.wunderwood.org
> >>>>> %2Fdata=02%7C01%7Cdemian.katz%40villanova.e
> >>>>>>>>>
> >>>>> du%7C1eef0604700a442deb7e08d8134b97fb%7C765a8de5cf9444f09cafae5bf8cf
> >>>>>>>>>
> >>>>> a366%7C0%7C0%7C637280562684672329sdata=0GyK5Tlq0PGsWxl%2FirJOVN
> >>>>>>>>> VaFCELlEChdxuLJ5RxdQs%3Dreserved=0  (my blog)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> -
> >>>>>>> Noble Paul
> >>>>>>
> >>>>>
> >>>
> >>
> >>
>
>

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Oakley, Craig (NIH/NLM/NCBI) [C]]

Trying think of a term that both fresh (and yet sort of standard already) and 
appropriate: how about IndexFetcher instead of "Slave"? And then "Master" could 
be "FetchedIndex" or "FetchedSource"

I think it could be beneficial to broaden the range of candidates.

From: Walter Underwood 
Sent: Thursday, June 18, 2020 10:34 PM
To: solr-user@lucene.apache.org 
Subject: Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

We don’t get to decide whether “master” is a problem. The rest of the world
has already decided that it is a problem.

Our task is to replace the terms “master” and “slave” in Solr.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

> On Jun 18, 2020, at 6:50 PM, Rahul Goswami  wrote:
>
> I agree with Phill, Noble and Ilan above. The problematic term is "slave"
> (not master) which I am all for changing if it causes less regression than
> removing BOTH master and slave. Since some people have pointed out Github
> changing the "master" terminology, in my personal opinion, it was not a
> measured response to addressing the bigger problem we are all trying to
> tackle. There is no concept of a "slave" branch, and "master" by itself is
> a pretty generic term (Is someone having "mastery" over a skill a bad
> thing?). I fear all it would end up achieving in the end with Github is a
> mess of broken build scripts at best.
> So +1 on "slave" being the problematic term IMO, not "master".
>
> On Thu, Jun 18, 2020 at 8:19 PM Phill Campbell
>  wrote:
>
>> Master - Worker
>> Master - Peon
>> Master - Helper
>> Master - Servant
>>
>> The term that is not wanted is “slave’. The term “master” is not a problem
>> IMO.
>>
>>> On Jun 18, 2020, at 3:59 PM, Jan Høydahl  wrote:
>>>
>>> I support Mike Drob and Trey Grainger. We shuold re-use the
>> leader/replica
>>> terminology from Cloud. Even if you hand-configure a master/slave cluster
>>> and orchestrate what doc goes to which node/shard, and hand-code your
>> shards
>>> parameter, you will still have a cluster where you’d send updates to the
>> leader of
>>> each shard and the replicas would replicate the index from the leader.
>>>
>>> Let’s instead find a new good name for the cluster type. Standalone kind
>> of works
>>> for me, but I see it can be confused with single-node. We have also
>> discussed
>>> replacing SolrCloud (which is a terrible name) with something more
>> descriptive.
>>>
>>> Today: SolrCloud vs Master/slave
>>> Alt A: SolrCloud vs Standalone
>>> Alt B: SolrCloud vs Legacy
>>> Alt C: Clustered vs Independent
>>> Alt D: Clustered vs Manual mode
>>>
>>> Jan
>>>
>>>> 18. jun. 2020 kl. 15:53 skrev Mike Drob :
>>>>
>>>> I personally think that using Solr cloud terminology for this would be
>> fine
>>>> with leader/follower. The leader is the one that accepts updates,
>> followers
>>>> cascade the updates somehow. The presence of ZK or election doesn’t
>> really
>>>> change this detail.
>>>>
>>>> However, if folks feel that it’s confusing, then I can’t tell them that
>>>> they’re not confused. Especially when they’re working with others who
>> have
>>>> less Solr experience than we do and are less familiar with the
>> intricacies.
>>>>
>>>> Primary/Replica seems acceptable. Coordinator instead of Overseer seems
>>>> acceptable.
>>>>
>>>> Would love to see this in 9.0!
>>>>
>>>> Mike
>>>>
>>>> On Thu, Jun 18, 2020 at 8:25 AM John Gallagher
>>>>  wrote:
>>>>
>>>>> While on the topic of renaming roles, I'd like to propose finding a
>> better
>>>>> term than "overseer" which has historical slavery connotations as well.
>>>>> Director, perhaps?
>>>>>
>>>>>
>>>>> John Gallagher
>>>>>
>>>>> On Thu, Jun 18, 2020 at 8:48 AM Jason Gerlowski >>
>>>>> wrote:
>>>>>
>>>>>> +1 to rename master/slave, and +1 to choosing terminology distinct
>>>>>> from what's used for SolrCloud.  I could be happy with several of the
>>>>>> proposed options.  Since a good few have been proposed though, maybe
>>>>>> an eventual vote thread is the most organized 

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Walter Underwood]

erhaps?
>>>> 
>>>> 
>>>> John Gallagher
>>>> 
>>>> On Thu, Jun 18, 2020 at 8:48 AM Jason Gerlowski 
>>>> wrote:
>>>> 
>>>>> +1 to rename master/slave, and +1 to choosing terminology distinct
>>>>> from what's used for SolrCloud.  I could be happy with several of the
>>>>> proposed options.  Since a good few have been proposed though, maybe
>>>>> an eventual vote thread is the most organized way to aggregate the
>>>>> opinions here.
>>>>> 
>>>>> I'm less positive about the prospect of changing the name of our
>>>>> primary git branch.  Most projects that contributors might come from,
>>>>> most tutorials out there to learn git, most tools built on top of git
>>>>> - the majority are going to assume "master" as the main branch.  I
>>>>> appreciate the change that Github is trying to effect in changing the
>>>>> default for new projects, but it'll be a long time before that
>>>>> competes with the huge bulk of projects, documentation, etc. out there
>>>>> using "master".  Our contributors are smart and I'm sure they'd figure
>>>>> it out if we used "main" or something else instead, but having a
>>>>> non-standard git setup would be one more "papercut" in understanding
>>>>> how to contribute to a project that already makes that harder than it
>>>>> should.
>>>>> 
>>>>> Jason
>>>>> 
>>>>> 
>>>>> On Thu, Jun 18, 2020 at 7:33 AM Demian Katz >> 
>>>>> wrote:
>>>>>> 
>>>>>> Regarding people having a problem with the word "master" -- GitHub is
>>>>> changing the default branch name away from "master," even in isolation
>>>> from
>>>>> a "slave" pairing... so the terminology seems to be falling out of
>> favor
>>>> in
>>>>> all contexts. See:
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> https://www.cnet.com/news/microsofts-github-is-removing-coding-terms-like-master-and-slave/
>>>>>> 
>>>>>> I'm not here to start a debate about the semantics of that, just to
>>>>> provide evidence that in some communities, the term "master" is causing
>>>>> concern all by itself. If we're going to make the change anyway, it
>> might
>>>>> be best to get it over with and pick the most appropriate terminology
>> we
>>>>> can agree upon, rather than trying to minimize the amount of change.
>> It's
>>>>> going to be backward breaking anyway, so we might as well do it all now
>>>>> rather than risk having to go through two separate breaking changes at
>>>>> different points in time.
>>>>>> 
>>>>>> - Demian
>>>>>> 
>>>>>> -Original Message-
>>>>>> From: Noble Paul 
>>>>>> Sent: Thursday, June 18, 2020 1:51 AM
>>>>>> To: solr-user@lucene.apache.org
>>>>>> Subject: [EXTERNAL] Re: Getting rid of Master/Slave nomenclature in
>>>> Solr
>>>>>> 
>>>>>> Looking at the code I see a 692 occurrences of the word "slave".
>>>>>> Mostly variable names and ref guide docs.
>>>>>> 
>>>>>> The word "slave" is present in the responses as well. Any change in
>> the
>>>>> request param/response payload is backward incompatible.
>>>>>> 
>>>>>> I have no objection to changing the names in ref guide and other
>>>>> internal variables. Going ahead with backward incompatible changes is
>>>>> painful. If somebody has the appetite to take it up, it's OK
>>>>>> 
>>>>>> If we must change, master/follower can be a good enough option.
>>>>>> 
>>>>>> master (noun): A man in charge of an organization or group.
>>>>>> master(adj) : having or showing very great skill or proficiency.
>>>>>> master(verb): acquire complete knowledge or skill in (a subject,
>>>>> technique, or art).
>>>>>> master (verb): gain control of; overcome.
>>>>>> 
>>>>>> I hope nobody has a problem with the term "master"
>>>>>> 
>>>>>> On Thu, Jun 18, 2020 at 3:19 PM Ilan Ginzburg 
>>>>> wrote:
>>>>>>> 
>>>>>>> Would master/follower work?
>>>>>>> 
>>>>>>> Half the rename work while still getting rid of the slavery
>>>>> connotation...
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu 18 Jun 2020 at 07:13, Walter Underwood >>>> 
>>>>> wrote:
>>>>>>> 
>>>>>>>>> On Jun 17, 2020, at 4:00 PM, Shawn Heisey 
>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> It has been interesting watching this discussion play out on
>>>>>>>>> multiple
>>>>>>>> open source mailing lists.  On other projects, I have seen a VERY
>>>>>>>> high level of resistance to these changes, which I find disturbing
>>>>>>>> and surprising.
>>>>>>>> 
>>>>>>>> Yes, it is nice to see everyone just pitch in and do it on this
>>>> list.
>>>>>>>> 
>>>>>>>> wunder
>>>>>>>> Walter Underwood
>>>>>>>> wun...@wunderwood.org
>>>>>>>> 
>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fobs
>>>>>>>> erver.wunderwood.org
>>>> %2Fdata=02%7C01%7Cdemian.katz%40villanova.e
>>>>>>>> 
>>>> du%7C1eef0604700a442deb7e08d8134b97fb%7C765a8de5cf9444f09cafae5bf8cf
>>>>>>>> 
>>>> a366%7C0%7C0%7C637280562684672329sdata=0GyK5Tlq0PGsWxl%2FirJOVN
>>>>>>>> VaFCELlEChdxuLJ5RxdQs%3Dreserved=0  (my blog)
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> -
>>>>>> Noble Paul
>>>>> 
>>>> 
>> 
>> 

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Trey Grainger]

 to a project that already makes that harder than it
> >>> should.
> >>>
> >>> Jason
> >>>
> >>>
> >>> On Thu, Jun 18, 2020 at 7:33 AM Demian Katz  >
> >>> wrote:
> >>>>
> >>>> Regarding people having a problem with the word "master" -- GitHub is
> >>> changing the default branch name away from "master," even in isolation
> >> from
> >>> a "slave" pairing... so the terminology seems to be falling out of
> favor
> >> in
> >>> all contexts. See:
> >>>>
> >>>>
> >>>
> >>
> https://www.cnet.com/news/microsofts-github-is-removing-coding-terms-like-master-and-slave/
> >>>>
> >>>> I'm not here to start a debate about the semantics of that, just to
> >>> provide evidence that in some communities, the term "master" is causing
> >>> concern all by itself. If we're going to make the change anyway, it
> might
> >>> be best to get it over with and pick the most appropriate terminology
> we
> >>> can agree upon, rather than trying to minimize the amount of change.
> It's
> >>> going to be backward breaking anyway, so we might as well do it all now
> >>> rather than risk having to go through two separate breaking changes at
> >>> different points in time.
> >>>>
> >>>> - Demian
> >>>>
> >>>> -Original Message-
> >>>> From: Noble Paul 
> >>>> Sent: Thursday, June 18, 2020 1:51 AM
> >>>> To: solr-user@lucene.apache.org
> >>>> Subject: [EXTERNAL] Re: Getting rid of Master/Slave nomenclature in
> >> Solr
> >>>>
> >>>> Looking at the code I see a 692 occurrences of the word "slave".
> >>>> Mostly variable names and ref guide docs.
> >>>>
> >>>> The word "slave" is present in the responses as well. Any change in
> the
> >>> request param/response payload is backward incompatible.
> >>>>
> >>>> I have no objection to changing the names in ref guide and other
> >>> internal variables. Going ahead with backward incompatible changes is
> >>> painful. If somebody has the appetite to take it up, it's OK
> >>>>
> >>>> If we must change, master/follower can be a good enough option.
> >>>>
> >>>> master (noun): A man in charge of an organization or group.
> >>>> master(adj) : having or showing very great skill or proficiency.
> >>>> master(verb): acquire complete knowledge or skill in (a subject,
> >>> technique, or art).
> >>>> master (verb): gain control of; overcome.
> >>>>
> >>>> I hope nobody has a problem with the term "master"
> >>>>
> >>>> On Thu, Jun 18, 2020 at 3:19 PM Ilan Ginzburg 
> >>> wrote:
> >>>>>
> >>>>> Would master/follower work?
> >>>>>
> >>>>> Half the rename work while still getting rid of the slavery
> >>> connotation...
> >>>>>
> >>>>>
> >>>>> On Thu 18 Jun 2020 at 07:13, Walter Underwood  >>>
> >>> wrote:
> >>>>>
> >>>>>>> On Jun 17, 2020, at 4:00 PM, Shawn Heisey 
> >>> wrote:
> >>>>>>>
> >>>>>>> It has been interesting watching this discussion play out on
> >>>>>>> multiple
> >>>>>> open source mailing lists.  On other projects, I have seen a VERY
> >>>>>> high level of resistance to these changes, which I find disturbing
> >>>>>> and surprising.
> >>>>>>
> >>>>>> Yes, it is nice to see everyone just pitch in and do it on this
> >> list.
> >>>>>>
> >>>>>> wunder
> >>>>>> Walter Underwood
> >>>>>> wun...@wunderwood.org
> >>>>>>
> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fobs
> >>>>>> erver.wunderwood.org
> >> %2Fdata=02%7C01%7Cdemian.katz%40villanova.e
> >>>>>>
> >> du%7C1eef0604700a442deb7e08d8134b97fb%7C765a8de5cf9444f09cafae5bf8cf
> >>>>>>
> >> a366%7C0%7C0%7C637280562684672329sdata=0GyK5Tlq0PGsWxl%2FirJOVN
> >>>>>> VaFCELlEChdxuLJ5RxdQs%3Dreserved=0  (my blog)
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> -
> >>>> Noble Paul
> >>>
> >>
>
>

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Walter Underwood]

gt;> appreciate the change that Github is trying to effect in changing the
>>>>>> default for new projects, but it'll be a long time before that
>>>>>> competes with the huge bulk of projects, documentation, etc. out there
>>>>>> using "master".  Our contributors are smart and I'm sure they'd figure
>>>>>> it out if we used "main" or something else instead, but having a
>>>>>> non-standard git setup would be one more "papercut" in understanding
>>>>>> how to contribute to a project that already makes that harder than it
>>>>>> should.
>>>>>> 
>>>>>> Jason
>>>>>> 
>>>>>> 
>>>>>> On Thu, Jun 18, 2020 at 7:33 AM Demian Katz <
>> demian.k...@villanova.edu>
>>>>>> wrote:
>>>>>>> 
>>>>>>> Regarding people having a problem with the word "master" -- GitHub is
>>>>>> changing the default branch name away from "master," even in isolation
>>>>> from
>>>>>> a "slave" pairing... so the terminology seems to be falling out of
>> favor
>>>>> in
>>>>>> all contexts. See:
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>> https://www.cnet.com/news/microsofts-github-is-removing-coding-terms-like-master-and-slave/
>>>>>>> 
>>>>>>> I'm not here to start a debate about the semantics of that, just to
>>>>>> provide evidence that in some communities, the term "master" is
>> causing
>>>>>> concern all by itself. If we're going to make the change anyway, it
>> might
>>>>>> be best to get it over with and pick the most appropriate terminology
>> we
>>>>>> can agree upon, rather than trying to minimize the amount of change.
>> It's
>>>>>> going to be backward breaking anyway, so we might as well do it all
>> now
>>>>>> rather than risk having to go through two separate breaking changes at
>>>>>> different points in time.
>>>>>>> 
>>>>>>> - Demian
>>>>>>> 
>>>>>>> -Original Message-
>>>>>>> From: Noble Paul 
>>>>>>> Sent: Thursday, June 18, 2020 1:51 AM
>>>>>>> To: solr-user@lucene.apache.org
>>>>>>> Subject: [EXTERNAL] Re: Getting rid of Master/Slave nomenclature in
>>>>> Solr
>>>>>>> 
>>>>>>> Looking at the code I see a 692 occurrences of the word "slave".
>>>>>>> Mostly variable names and ref guide docs.
>>>>>>> 
>>>>>>> The word "slave" is present in the responses as well. Any change in
>> the
>>>>>> request param/response payload is backward incompatible.
>>>>>>> 
>>>>>>> I have no objection to changing the names in ref guide and other
>>>>>> internal variables. Going ahead with backward incompatible changes is
>>>>>> painful. If somebody has the appetite to take it up, it's OK
>>>>>>> 
>>>>>>> If we must change, master/follower can be a good enough option.
>>>>>>> 
>>>>>>> master (noun): A man in charge of an organization or group.
>>>>>>> master(adj) : having or showing very great skill or proficiency.
>>>>>>> master(verb): acquire complete knowledge or skill in (a subject,
>>>>>> technique, or art).
>>>>>>> master (verb): gain control of; overcome.
>>>>>>> 
>>>>>>> I hope nobody has a problem with the term "master"
>>>>>>> 
>>>>>>> On Thu, Jun 18, 2020 at 3:19 PM Ilan Ginzburg 
>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Would master/follower work?
>>>>>>>> 
>>>>>>>> Half the rename work while still getting rid of the slavery
>>>>>> connotation...
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Thu 18 Jun 2020 at 07:13, Walter Underwood <
>> wun...@wunderwood.org
>>>>>> 
>>>>>> wrote:
>>>>>>>> 
>>>>>>>>>> On Jun 17, 2020, at 4:00 PM, Shawn Heisey 
>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> It has been interesting watching this discussion play out on
>>>>>>>>>> multiple
>>>>>>>>> open source mailing lists.  On other projects, I have seen a VERY
>>>>>>>>> high level of resistance to these changes, which I find disturbing
>>>>>>>>> and surprising.
>>>>>>>>> 
>>>>>>>>> Yes, it is nice to see everyone just pitch in and do it on this
>>>>> list.
>>>>>>>>> 
>>>>>>>>> wunder
>>>>>>>>> Walter Underwood
>>>>>>>>> wun...@wunderwood.org
>>>>>>>>> 
>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fobs
>>>>>>>>> erver.wunderwood.org
>>>>> %2Fdata=02%7C01%7Cdemian.katz%40villanova.e
>>>>>>>>> 
>>>>> du%7C1eef0604700a442deb7e08d8134b97fb%7C765a8de5cf9444f09cafae5bf8cf
>>>>>>>>> 
>>>>> a366%7C0%7C0%7C637280562684672329sdata=0GyK5Tlq0PGsWxl%2FirJOVN
>>>>>>>>> VaFCELlEChdxuLJ5RxdQs%3Dreserved=0  (my blog)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> -
>>>>>>> Noble Paul
>>>>>> 
>>>>> 
>>> 
>> 
>> 

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Rahul Goswami]

gt;>
> >>>> Jason
> >>>>
> >>>>
> >>>> On Thu, Jun 18, 2020 at 7:33 AM Demian Katz <
> demian.k...@villanova.edu>
> >>>> wrote:
> >>>>>
> >>>>> Regarding people having a problem with the word "master" -- GitHub is
> >>>> changing the default branch name away from "master," even in isolation
> >>> from
> >>>> a "slave" pairing... so the terminology seems to be falling out of
> favor
> >>> in
> >>>> all contexts. See:
> >>>>>
> >>>>>
> >>>>
> >>>
> https://www.cnet.com/news/microsofts-github-is-removing-coding-terms-like-master-and-slave/
> >>>>>
> >>>>> I'm not here to start a debate about the semantics of that, just to
> >>>> provide evidence that in some communities, the term "master" is
> causing
> >>>> concern all by itself. If we're going to make the change anyway, it
> might
> >>>> be best to get it over with and pick the most appropriate terminology
> we
> >>>> can agree upon, rather than trying to minimize the amount of change.
> It's
> >>>> going to be backward breaking anyway, so we might as well do it all
> now
> >>>> rather than risk having to go through two separate breaking changes at
> >>>> different points in time.
> >>>>>
> >>>>> - Demian
> >>>>>
> >>>>> -Original Message-
> >>>>> From: Noble Paul 
> >>>>> Sent: Thursday, June 18, 2020 1:51 AM
> >>>>> To: solr-user@lucene.apache.org
> >>>>> Subject: [EXTERNAL] Re: Getting rid of Master/Slave nomenclature in
> >>> Solr
> >>>>>
> >>>>> Looking at the code I see a 692 occurrences of the word "slave".
> >>>>> Mostly variable names and ref guide docs.
> >>>>>
> >>>>> The word "slave" is present in the responses as well. Any change in
> the
> >>>> request param/response payload is backward incompatible.
> >>>>>
> >>>>> I have no objection to changing the names in ref guide and other
> >>>> internal variables. Going ahead with backward incompatible changes is
> >>>> painful. If somebody has the appetite to take it up, it's OK
> >>>>>
> >>>>> If we must change, master/follower can be a good enough option.
> >>>>>
> >>>>> master (noun): A man in charge of an organization or group.
> >>>>> master(adj) : having or showing very great skill or proficiency.
> >>>>> master(verb): acquire complete knowledge or skill in (a subject,
> >>>> technique, or art).
> >>>>> master (verb): gain control of; overcome.
> >>>>>
> >>>>> I hope nobody has a problem with the term "master"
> >>>>>
> >>>>> On Thu, Jun 18, 2020 at 3:19 PM Ilan Ginzburg 
> >>>> wrote:
> >>>>>>
> >>>>>> Would master/follower work?
> >>>>>>
> >>>>>> Half the rename work while still getting rid of the slavery
> >>>> connotation...
> >>>>>>
> >>>>>>
> >>>>>> On Thu 18 Jun 2020 at 07:13, Walter Underwood <
> wun...@wunderwood.org
> >>>>
> >>>> wrote:
> >>>>>>
> >>>>>>>> On Jun 17, 2020, at 4:00 PM, Shawn Heisey 
> >>>> wrote:
> >>>>>>>>
> >>>>>>>> It has been interesting watching this discussion play out on
> >>>>>>>> multiple
> >>>>>>> open source mailing lists.  On other projects, I have seen a VERY
> >>>>>>> high level of resistance to these changes, which I find disturbing
> >>>>>>> and surprising.
> >>>>>>>
> >>>>>>> Yes, it is nice to see everyone just pitch in and do it on this
> >>> list.
> >>>>>>>
> >>>>>>> wunder
> >>>>>>> Walter Underwood
> >>>>>>> wun...@wunderwood.org
> >>>>>>>
> >>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fobs
> >>>>>>> erver.wunderwood.org
> >>> %2Fdata=02%7C01%7Cdemian.katz%40villanova.e
> >>>>>>>
> >>> du%7C1eef0604700a442deb7e08d8134b97fb%7C765a8de5cf9444f09cafae5bf8cf
> >>>>>>>
> >>> a366%7C0%7C0%7C637280562684672329sdata=0GyK5Tlq0PGsWxl%2FirJOVN
> >>>>>>> VaFCELlEChdxuLJ5RxdQs%3Dreserved=0  (my blog)
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> -
> >>>>> Noble Paul
> >>>>
> >>>
> >
>
>

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Phill Campbell]

Master - Worker
Master - Peon
Master - Helper
Master - Servant

The term that is not wanted is “slave’. The term “master” is not a problem IMO.

> On Jun 18, 2020, at 3:59 PM, Jan Høydahl  wrote:
> 
> I support Mike Drob and Trey Grainger. We shuold re-use the leader/replica
> terminology from Cloud. Even if you hand-configure a master/slave cluster
> and orchestrate what doc goes to which node/shard, and hand-code your shards
> parameter, you will still have a cluster where you’d send updates to the 
> leader of 
> each shard and the replicas would replicate the index from the leader.
> 
> Let’s instead find a new good name for the cluster type. Standalone kind of 
> works
> for me, but I see it can be confused with single-node. We have also discussed
> replacing SolrCloud (which is a terrible name) with something more 
> descriptive.
> 
> Today: SolrCloud vs Master/slave
> Alt A: SolrCloud vs Standalone
> Alt B: SolrCloud vs Legacy
> Alt C: Clustered vs Independent
> Alt D: Clustered vs Manual mode
> 
> Jan
> 
>> 18. jun. 2020 kl. 15:53 skrev Mike Drob :
>> 
>> I personally think that using Solr cloud terminology for this would be fine
>> with leader/follower. The leader is the one that accepts updates, followers
>> cascade the updates somehow. The presence of ZK or election doesn’t really
>> change this detail.
>> 
>> However, if folks feel that it’s confusing, then I can’t tell them that
>> they’re not confused. Especially when they’re working with others who have
>> less Solr experience than we do and are less familiar with the intricacies.
>> 
>> Primary/Replica seems acceptable. Coordinator instead of Overseer seems
>> acceptable.
>> 
>> Would love to see this in 9.0!
>> 
>> Mike
>> 
>> On Thu, Jun 18, 2020 at 8:25 AM John Gallagher
>>  wrote:
>> 
>>> While on the topic of renaming roles, I'd like to propose finding a better
>>> term than "overseer" which has historical slavery connotations as well.
>>> Director, perhaps?
>>> 
>>> 
>>> John Gallagher
>>> 
>>> On Thu, Jun 18, 2020 at 8:48 AM Jason Gerlowski 
>>> wrote:
>>> 
>>>> +1 to rename master/slave, and +1 to choosing terminology distinct
>>>> from what's used for SolrCloud.  I could be happy with several of the
>>>> proposed options.  Since a good few have been proposed though, maybe
>>>> an eventual vote thread is the most organized way to aggregate the
>>>> opinions here.
>>>> 
>>>> I'm less positive about the prospect of changing the name of our
>>>> primary git branch.  Most projects that contributors might come from,
>>>> most tutorials out there to learn git, most tools built on top of git
>>>> - the majority are going to assume "master" as the main branch.  I
>>>> appreciate the change that Github is trying to effect in changing the
>>>> default for new projects, but it'll be a long time before that
>>>> competes with the huge bulk of projects, documentation, etc. out there
>>>> using "master".  Our contributors are smart and I'm sure they'd figure
>>>> it out if we used "main" or something else instead, but having a
>>>> non-standard git setup would be one more "papercut" in understanding
>>>> how to contribute to a project that already makes that harder than it
>>>> should.
>>>> 
>>>> Jason
>>>> 
>>>> 
>>>> On Thu, Jun 18, 2020 at 7:33 AM Demian Katz 
>>>> wrote:
>>>>> 
>>>>> Regarding people having a problem with the word "master" -- GitHub is
>>>> changing the default branch name away from "master," even in isolation
>>> from
>>>> a "slave" pairing... so the terminology seems to be falling out of favor
>>> in
>>>> all contexts. See:
>>>>> 
>>>>> 
>>>> 
>>> https://www.cnet.com/news/microsofts-github-is-removing-coding-terms-like-master-and-slave/
>>>>> 
>>>>> I'm not here to start a debate about the semantics of that, just to
>>>> provide evidence that in some communities, the term "master" is causing
>>>> concern all by itself. If we're going to make the change anyway, it might
>>>> be best to get it over with and pick the most appropriate terminology we
>>>> can agree upon, rather than trying to minimize the amount of change. It's
>>>> going to be backwa

Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr

[Jan Høydahl]

I support Mike Drob and Trey Grainger. We shuold re-use the leader/replica
terminology from Cloud. Even if you hand-configure a master/slave cluster
and orchestrate what doc goes to which node/shard, and hand-code your shards
parameter, you will still have a cluster where you’d send updates to the leader 
of 
each shard and the replicas would replicate the index from the leader.

Let’s instead find a new good name for the cluster type. Standalone kind of 
works
for me, but I see it can be confused with single-node. We have also discussed
replacing SolrCloud (which is a terrible name) with something more descriptive.

Today: SolrCloud vs Master/slave
Alt A: SolrCloud vs Standalone
Alt B: SolrCloud vs Legacy
Alt C: Clustered vs Independent
Alt D: Clustered vs Manual mode

Jan

> 18. jun. 2020 kl. 15:53 skrev Mike Drob :
> 
> I personally think that using Solr cloud terminology for this would be fine
> with leader/follower. The leader is the one that accepts updates, followers
> cascade the updates somehow. The presence of ZK or election doesn’t really
> change this detail.
> 
> However, if folks feel that it’s confusing, then I can’t tell them that
> they’re not confused. Especially when they’re working with others who have
> less Solr experience than we do and are less familiar with the intricacies.
> 
> Primary/Replica seems acceptable. Coordinator instead of Overseer seems
> acceptable.
> 
> Would love to see this in 9.0!
> 
> Mike
> 
> On Thu, Jun 18, 2020 at 8:25 AM John Gallagher
>  wrote:
> 
>> While on the topic of renaming roles, I'd like to propose finding a better
>> term than "overseer" which has historical slavery connotations as well.
>> Director, perhaps?
>> 
>> 
>> John Gallagher
>> 
>> On Thu, Jun 18, 2020 at 8:48 AM Jason Gerlowski 
>> wrote:
>> 
>>> +1 to rename master/slave, and +1 to choosing terminology distinct
>>> from what's used for SolrCloud.  I could be happy with several of the
>>> proposed options.  Since a good few have been proposed though, maybe
>>> an eventual vote thread is the most organized way to aggregate the
>>> opinions here.
>>> 
>>> I'm less positive about the prospect of changing the name of our
>>> primary git branch.  Most projects that contributors might come from,
>>> most tutorials out there to learn git, most tools built on top of git
>>> - the majority are going to assume "master" as the main branch.  I
>>> appreciate the change that Github is trying to effect in changing the
>>> default for new projects, but it'll be a long time before that
>>> competes with the huge bulk of projects, documentation, etc. out there
>>> using "master".  Our contributors are smart and I'm sure they'd figure
>>> it out if we used "main" or something else instead, but having a
>>> non-standard git setup would be one more "papercut" in understanding
>>> how to contribute to a project that already makes that harder than it
>>> should.
>>> 
>>> Jason
>>> 
>>> 
>>> On Thu, Jun 18, 2020 at 7:33 AM Demian Katz 
>>> wrote:
>>>> 
>>>> Regarding people having a problem with the word "master" -- GitHub is
>>> changing the default branch name away from "master," even in isolation
>> from
>>> a "slave" pairing... so the terminology seems to be falling out of favor
>> in
>>> all contexts. See:
>>>> 
>>>> 
>>> 
>> https://www.cnet.com/news/microsofts-github-is-removing-coding-terms-like-master-and-slave/
>>>> 
>>>> I'm not here to start a debate about the semantics of that, just to
>>> provide evidence that in some communities, the term "master" is causing
>>> concern all by itself. If we're going to make the change anyway, it might
>>> be best to get it over with and pick the most appropriate terminology we
>>> can agree upon, rather than trying to minimize the amount of change. It's
>>> going to be backward breaking anyway, so we might as well do it all now
>>> rather than risk having to go through two separate breaking changes at
>>> different points in time.
>>>> 
>>>> - Demian
>>>> 
>>>> -Original Message-
>>>> From: Noble Paul 
>>>> Sent: Thursday, June 18, 2020 1:51 AM
>>>> To: solr-user@lucene.apache.org
>>>> Subject: [EXTERNAL] Re: Getting rid of Master/Slave nomenclature in
>> Solr
>>>> 
>>>> Looking at the code I see a 692 occurrences of t