RE: Getting rid of Master/Slave nomenclature in Solr

[Jamie Gruener]

Marcus,

Thank you for tackling this. I'm not a developer, just a user, so my ability to 
help is limited to moral support. And I support your efforts 100%.

Thank you,

--Jamie

-Original Message-
From: Marcus Eagan  
Sent: Monday, August 3, 2020 12:15 PM
To: solr-user@lucene.apache.org
Subject: Re: Getting rid of Master/Slave nomenclature in Solr

Here is some of the work I did to remedy this effort before I knew about this 
email:

https://github.com/apache/lucene-solr/pull/1712

https://issues.apache.org/jira/browse/SOLR-14702page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=17169865

It makes me sick to read master/slave and this issue has alienated a buddy I've 
tried to recruit to volunteer on the project. All comments welcome, but please 
read the above docs as I will review this email thread now to understand what 
has already been discussed. I put in a lot of work to get this solid.

Happy to discuss.

Marcus

On 2020/06/17 19:37:20, Anshum Gupta wrote:

> Hi everyone,>

>

> Moving a conversation that was happening on the PMC list to the public>

> forum. Most of the following is just me recapping the conversation that has>

> happened so far.>

>

> Some members of the community have been discussing getting rid of the>

> master/slave nomenclature from Solr.>

>

> While this may require a non-trivial effort, a general consensus so far>

> seems to be to start this process and switch over incrementally, if a>

> single change ends up being too big.>

>

> There have been a lot of suggestions around what the new nomenclature might>

> look like, a few people don’t want to overlap the naming here with what>

> already exists in SolrCloud i.e. leader/follower.>

>

> Primary/Replica was an option that was suggested based on what other>

> vendors are moving towards based on Wikipedia:>

> https://en.wikipedia.org/wiki/Master/slave_(technology) >

> , however there were concerns around the use of “replica” as that denotes a>

> very specific concept in SolrCloud. Current terminology clearly>

> differentiates the use of the traditional replication model from SolrCloud>

> and reusing the names would make it difficult for that to happen.>

>

> There were similar concerns around using Leader/follower.>

>

> Let’s continue this conversation here while making sure that we converge>

> without much bike-shedding.>

>

> -Anshum>

>

Sent via Superhuman ( https://sprh.mn/?vip=m...@marcuseagan.com )

Re: Getting rid of Master/Slave nomenclature in Solr

[Marcus Eagan]

Here is some of the work I did to remedy this effort before I knew about this 
email:

https://github.com/apache/lucene-solr/pull/1712

https://issues.apache.org/jira/browse/SOLR-14702page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=17169865

It makes me sick to read master/slave and this issue has alienated a buddy I've 
tried to recruit to volunteer on the project. All comments welcome, but please 
read the above docs as I will review this email thread now to understand what 
has already been discussed. I put in a lot of work to get this solid.

Happy to discuss.

Marcus

On 2020/06/17 19:37:20, Anshum Gupta wrote:

> Hi everyone,>

>

> Moving a conversation that was happening on the PMC list to the public>

> forum. Most of the following is just me recapping the conversation that has>

> happened so far.>

>

> Some members of the community have been discussing getting rid of the>

> master/slave nomenclature from Solr.>

>

> While this may require a non-trivial effort, a general consensus so far>

> seems to be to start this process and switch over incrementally, if a>

> single change ends up being too big.>

>

> There have been a lot of suggestions around what the new nomenclature might>

> look like, a few people don’t want to overlap the naming here with what>

> already exists in SolrCloud i.e. leader/follower.>

>

> Primary/Replica was an option that was suggested based on what other>

> vendors are moving towards based on Wikipedia:>

> https://en.wikipedia.org/wiki/Master/slave_(technology) >

> , however there were concerns around the use of “replica” as that denotes a>

> very specific concept in SolrCloud. Current terminology clearly>

> differentiates the use of the traditional replication model from SolrCloud>

> and reusing the names would make it difficult for that to happen.>

>

> There were similar concerns around using Leader/follower.>

>

> Let’s continue this conversation here while making sure that we converge>

> without much bike-shedding.>

>

> -Anshum>

>

Sent via Superhuman ( https://sprh.mn/?vip=m...@marcuseagan.com )

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: Getting rid of Master/Slave nomenclature in Solr

[David Cumings]

Time to decouple from the weighty semantics of human experience and look to
nature?

queens/workers/drones/swarms?




On Wed, 17 Jun 2020 at 20:38, Anshum Gupta  wrote:

> Hi everyone,
>
> Moving a conversation that was happening on the PMC list to the public
> forum. Most of the following is just me recapping the conversation that has
> happened so far.
>
> Some members of the community have been discussing getting rid of the
> master/slave nomenclature from Solr.
>
> While this may require a non-trivial effort, a general consensus so far
> seems to be to start this process and switch over incrementally, if a
> single change ends up being too big.
>
> There have been a lot of suggestions around what the new nomenclature might
> look like, a few people don’t want to overlap the naming here with what
> already exists in SolrCloud i.e. leader/follower.
>
> Primary/Replica was an option that was suggested based on what other
> vendors are moving towards based on Wikipedia:
> https://en.wikipedia.org/wiki/Master/slave_(technology)
> , however there were concerns around the use of “replica” as that denotes a
> very specific concept in SolrCloud. Current terminology clearly
> differentiates the use of the traditional replication model from SolrCloud
> and reusing the names would make it difficult for that to happen.
>
> There were similar concerns around using Leader/follower.
>
> Let’s continue this conversation here while making sure that we converge
> without much bike-shedding.
>
> -Anshum
>


-- 
David Cumings
AU: +61 498 137 841
US: +1 (929) 291-0801
UK: +44 7725 057 500 <-- Currently in the UK
IN: +91 82771 96058
d...@cumings.com

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

Re: Getting rid of Master/Slave nomenclature in Solr

[Chris Hostetter]

First off: Forgive me if my comments/questions are redundent or uninformed 
bsaed o nthe larger discussion taking place.  I have not 
caught up on the whole thread before replying -- but that's solely based 
on a lack of time on my part, not a lack of willingness to embrace this 
change.


>From skimming a handful of messages in this thread, there's one aspect of 
the discussion -- particularly in the context of "should we or should we 
not re-use / overlap with 'SolrCloud' terminology" -- that seems (from 
limited review) to be getting overlooked...


Even today, before you start to consider if/what to replace the M & S 
terms with, we've already reach the point where the 
replication/IndexFetcher code can use those tems in confusing/missleading 
ways -- particularly in the context of SolrCloud, recovery, backups, 
etc...

I think a meaningful conversation about retiring the existing terminology 
should probably take into account at least 3 distinct questions:

#1 - what terminology should be used/expected/documented in non-SolrCloud 
usage of explicitly configuring "classic" ReplicationHandler in 
solrconfig.xml ?

#2 - what terminology should be used in the source code of
ReplicationHandler / IndexFetcher related code?

#3 - what terminology should be used in the *log* messages of 
ReplicationHandler / IndexFetcher related code? and (# 3a) should that 
terminology vary based on the type of cluster and when/why/how the 
replication code is being used?


In reverse order: My personal answers would be:

#3a - yes

#3 - I think we can & should tweak the replication code to understand 
the context it's being used in and adjust it's log/error messages accordingly

#2 - w/o digging into the code in depth here, i supect something like 
"remoteSource + localDest" would probably work well in the context of 
"index fetching"  -- or even just simply "fetchSource", w/o any need for a 
'slave' term equivilent because the context is usually just "local".  ... 
i don't think there any contexts where it really matters but 
"replicationSource + replicationDest" code be more generic terms for 
situations where the code isn't specifically a "I am a core that's doing 
fetching" context (alternatively: "remoteSource + localDest" could have 
parity with "localSource + remoteDest" if there are any situations i'm not 
thinking of where we "push" an index)

#1 - this is the least interesting question to me personally (given that 
we are moving away from it in general in favor of solr cloud), but i think 
in the context of how the terms are used in solrconfig.xml even the 
original M & S terms have never really made much sense if you look at 
where/how they are used in the configuration -- particularly in the 
context of the "repeater" use case.  I would suggest as a straw man 
replacing the 'name="master"' config block with a 
'name="provideSnapshots"' block using hte same options; and replace the 
'name="slave"' config block with 'name="fetchSnapshots"' config block, 
using mostly the same options, except replacing 'masterUrl' with 
'sourceUrl'.



-Hoss
http://www.lucidworks.com/

Re: Getting rid of Master/Slave nomenclature in Solr

[Walter Underwood]

Actually, the term “master” is a problem, so master/follower doesn’t work.

GitLab is renaming the master branch to main.

Rice University renamed College Masters to College Magisters in 2017.

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

> On Jun 18, 2020, at 1:03 AM, Atita Arora  wrote:
> 
> +1 Noble and Ilan !!
> 
> 
> 
> On Thu, Jun 18, 2020 at 7:51 AM Noble Paul  wrote:
> 
>> 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
 http://observer.wunderwood.org/  (my blog)
 
 
>> 
>> 
>> 
>> --
>> -
>> Noble Paul
>> 

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

[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 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:
> > 

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

[John Gallagher]

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: Getting rid of Master/Slave nomenclature in Solr

[Mark H. Wood]

Primary / satellite?

-- 
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] Re: Getting rid of Master/Slave nomenclature in Solr

[Jason Gerlowski]

+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] Re: Getting rid of Master/Slave nomenclature in Solr

[Demian Katz]

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: Getting rid of Master/Slave nomenclature in Solr

[Atita Arora]

+1 Noble and Ilan !!



On Thu, Jun 18, 2020 at 7:51 AM Noble Paul  wrote:

> 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
> > > http://observer.wunderwood.org/  (my blog)
> > >
> > >
>
>
>
> --
> -
> Noble Paul
>

Re: Getting rid of Master/Slave nomenclature in Solr

[Noble Paul]

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
> > http://observer.wunderwood.org/  (my blog)
> >
> >



-- 
-
Noble Paul

Re: Getting rid of Master/Slave nomenclature in Solr

[Ilan Ginzburg]

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
> http://observer.wunderwood.org/  (my blog)
>
>

Re: Getting rid of Master/Slave nomenclature in Solr

[Walter Underwood]

> 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
http://observer.wunderwood.org/  (my blog)

Re: Getting rid of Master/Slave nomenclature in Solr

[Walter Underwood]

Master/slave is not going away in our company. That cluster has zero downtime
in five years. I can’t say that about our Solr Cloud clusters.

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

> On Jun 17, 2020, at 9:36 PM, Noble Paul  wrote:
> 
> I really do not see a reason why a master/slave terminology is a problem.
> We do not have slavery anywhere in the world. Should we also remove it from
> the dictionary?
> 
> The old mode is going to go away anyway. Why waste time bikeshedding on
> this?
> 
> On Thu, Jun 18, 2020, 12:04 PM Trey Grainger  wrote:
> 
>> @Shawn,
>> 
>> Ok, yeah, apologies, my semantics were wrong.
>> 
>> I was thinking that a TLog replica is a follower role only and becomes an
>> NRT replica if it gets elected leader. From a pure semantics standpoint,
>> though, I guess technically the TLog replica doesn't "become" an NRT
>> replica, but just "acts the same" as if it was an NRT replica when it gets
>> elected as leader. From the docs regarding TLog replicas: "This type of
>> replica maintains a transaction log but does not index document changes
>> locally... When this type of replica needs to update its index, it does so
>> by replicating the index from the leader... If it does become a leader, it
>> will behave the same as if it was a NRT type of replica."
>> 
>> The Tlog replicas are a bit of a red herring to the point I was making,
>> though, which is that Pull Replicas in SolrCloud mode and Slaves in
>> non-SolrCloud mode both just pull the index from the leader/master and as
>> opposed to updates being pushed the other way. As such, I don't see a
>> meaningful distinction between master/slave and leader/follower behavior in
>> non-SolrCloud mode vs. SolrCloud mode for the specific functionality we're
>> talking about renaming (Solr cores that pull indices from other Solr
>> cores).
>> 
>> At any rate, this is not a hill I care to die on. My belief is that it's
>> better to have consistent terminology for what I see as essentially the
>> same functionality. I respect that others disagree and would rather
>> introduce new terminology to clearly distinguish between modes. Regardless
>> of the naming decided on, I'm in support of removing the master/slave
>> nomenclature.
>> 
>> Trey Grainger
>> Founder, Searchkernel
>> https://searchkernel.com
>> 
>> On Wed, Jun 17, 2020 at 7:00 PM Shawn Heisey  wrote:
>> 
>>> On 6/17/2020 2:36 PM, Trey Grainger wrote:
 2) TLOG - which can only serve in the role of follower
>>> 
>>> This is inaccurate.  TLOG can become leader.  If that happens, then it
>>> functions exactly like an NRT leader.
>>> 
>>> I'm aware that saying the following is bikeshedding ... but I do think
>>> it would be as mistake to use any existing SolrCloud terminology for
>>> non-cloud deployments, including the word "replica".  The top contenders
>>> I have seen to replace master/slave in Solr are primary/secondary and
>>> publisher/subscriber.
>>> 
>>> 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.
>>> 
>>> Thanks,
>>> Shawn
>>> 
>> 

Re: Getting rid of Master/Slave nomenclature in Solr

[Noble Paul]

I really do not see a reason why a master/slave terminology is a problem.
We do not have slavery anywhere in the world. Should we also remove it from
the dictionary?

The old mode is going to go away anyway. Why waste time bikeshedding on
this?

On Thu, Jun 18, 2020, 12:04 PM Trey Grainger  wrote:

> @Shawn,
>
> Ok, yeah, apologies, my semantics were wrong.
>
> I was thinking that a TLog replica is a follower role only and becomes an
> NRT replica if it gets elected leader. From a pure semantics standpoint,
> though, I guess technically the TLog replica doesn't "become" an NRT
> replica, but just "acts the same" as if it was an NRT replica when it gets
> elected as leader. From the docs regarding TLog replicas: "This type of
> replica maintains a transaction log but does not index document changes
> locally... When this type of replica needs to update its index, it does so
> by replicating the index from the leader... If it does become a leader, it
> will behave the same as if it was a NRT type of replica."
>
> The Tlog replicas are a bit of a red herring to the point I was making,
> though, which is that Pull Replicas in SolrCloud mode and Slaves in
> non-SolrCloud mode both just pull the index from the leader/master and as
> opposed to updates being pushed the other way. As such, I don't see a
> meaningful distinction between master/slave and leader/follower behavior in
> non-SolrCloud mode vs. SolrCloud mode for the specific functionality we're
> talking about renaming (Solr cores that pull indices from other Solr
> cores).
>
> At any rate, this is not a hill I care to die on. My belief is that it's
> better to have consistent terminology for what I see as essentially the
> same functionality. I respect that others disagree and would rather
> introduce new terminology to clearly distinguish between modes. Regardless
> of the naming decided on, I'm in support of removing the master/slave
> nomenclature.
>
> Trey Grainger
> Founder, Searchkernel
> https://searchkernel.com
>
> On Wed, Jun 17, 2020 at 7:00 PM Shawn Heisey  wrote:
>
> > On 6/17/2020 2:36 PM, Trey Grainger wrote:
> > > 2) TLOG - which can only serve in the role of follower
> >
> > This is inaccurate.  TLOG can become leader.  If that happens, then it
> > functions exactly like an NRT leader.
> >
> > I'm aware that saying the following is bikeshedding ... but I do think
> > it would be as mistake to use any existing SolrCloud terminology for
> > non-cloud deployments, including the word "replica".  The top contenders
> > I have seen to replace master/slave in Solr are primary/secondary and
> > publisher/subscriber.
> >
> > 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.
> >
> > Thanks,
> > Shawn
> >
>

Re: Getting rid of Master/Slave nomenclature in Solr

[Trey Grainger]

@Shawn,

Ok, yeah, apologies, my semantics were wrong.

I was thinking that a TLog replica is a follower role only and becomes an
NRT replica if it gets elected leader. From a pure semantics standpoint,
though, I guess technically the TLog replica doesn't "become" an NRT
replica, but just "acts the same" as if it was an NRT replica when it gets
elected as leader. From the docs regarding TLog replicas: "This type of
replica maintains a transaction log but does not index document changes
locally... When this type of replica needs to update its index, it does so
by replicating the index from the leader... If it does become a leader, it
will behave the same as if it was a NRT type of replica."

The Tlog replicas are a bit of a red herring to the point I was making,
though, which is that Pull Replicas in SolrCloud mode and Slaves in
non-SolrCloud mode both just pull the index from the leader/master and as
opposed to updates being pushed the other way. As such, I don't see a
meaningful distinction between master/slave and leader/follower behavior in
non-SolrCloud mode vs. SolrCloud mode for the specific functionality we're
talking about renaming (Solr cores that pull indices from other Solr cores).

At any rate, this is not a hill I care to die on. My belief is that it's
better to have consistent terminology for what I see as essentially the
same functionality. I respect that others disagree and would rather
introduce new terminology to clearly distinguish between modes. Regardless
of the naming decided on, I'm in support of removing the master/slave
nomenclature.

Trey Grainger
Founder, Searchkernel
https://searchkernel.com

On Wed, Jun 17, 2020 at 7:00 PM Shawn Heisey  wrote:

> On 6/17/2020 2:36 PM, Trey Grainger wrote:
> > 2) TLOG - which can only serve in the role of follower
>
> This is inaccurate.  TLOG can become leader.  If that happens, then it
> functions exactly like an NRT leader.
>
> I'm aware that saying the following is bikeshedding ... but I do think
> it would be as mistake to use any existing SolrCloud terminology for
> non-cloud deployments, including the word "replica".  The top contenders
> I have seen to replace master/slave in Solr are primary/secondary and
> publisher/subscriber.
>
> 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.
>
> Thanks,
> Shawn
>

Re: Getting rid of Master/Slave nomenclature in Solr

[Michael Gibney]

I agree with Shawn that the top contenders so far (from my
perspective) are "primary/secondary" and "publisher/subscriber", and
agree with Walter that whatever term pair is used should ideally be
usable *as a pair* (to identify a cluster type) in addition to
individually (to identify the individual roles in that cluster).

To take the "bikeshedding" metaphor in another direction, I'd submit
"hub/spoke"? It's a little overloaded, but afaict mainly in domains
other than cluster architecture. It's very usable as a pair; it
manages to convey the singular nature of the "hub" and the
equivalent/final nature of the "spokes" in a way that
"primary/secondary" doesn't really; and it avoids implying an active
role in cluster maintenance for the "hub" (cf. "publisher", which
could be misleading in this regard).

Michael

On Wed, Jun 17, 2020 at 9:12 PM Scott Cote  wrote:
>
> Perhaps  Apache could provide a nomenclature suggestion that the projects 
> could adopt.   This would stand well for the whole Apache  community in 
> regards to BLM.
> My two cents as a “user”
> Good luck.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Wednesday, June 17, 2020, 6:00 PM, Shawn Heisey  
> wrote:
>
> On 6/17/2020 2:36 PM, Trey Grainger wrote:
> > 2) TLOG - which can only serve in the role of follower
>
> This is inaccurate.  TLOG can become leader.  If that happens, then it
> functions exactly like an NRT leader.
>
> I'm aware that saying the following is bikeshedding ... but I do think
> it would be as mistake to use any existing SolrCloud terminology for
> non-cloud deployments, including the word "replica".  The top contenders
> I have seen to replace master/slave in Solr are primary/secondary and
> publisher/subscriber.
>
> 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.
>
> Thanks,
> Shawn
>
>
>

Re: Getting rid of Master/Slave nomenclature in Solr

[Scott Cote]

Perhaps  Apache could provide a nomenclature suggestion that the projects could 
adopt.   This would stand well for the whole Apache  community in regards to 
BLM.
My two cents as a “user” 
Good luck.


Sent from Yahoo Mail for iPhone


On Wednesday, June 17, 2020, 6:00 PM, Shawn Heisey  wrote:

On 6/17/2020 2:36 PM, Trey Grainger wrote:
> 2) TLOG - which can only serve in the role of follower

This is inaccurate.  TLOG can become leader.  If that happens, then it 
functions exactly like an NRT leader.

I'm aware that saying the following is bikeshedding ... but I do think 
it would be as mistake to use any existing SolrCloud terminology for 
non-cloud deployments, including the word "replica".  The top contenders 
I have seen to replace master/slave in Solr are primary/secondary and 
publisher/subscriber.

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.

Thanks,
Shawn

Re: Getting rid of Master/Slave nomenclature in Solr

[Shawn Heisey]

On 6/17/2020 2:36 PM, Trey Grainger wrote:

2) TLOG - which can only serve in the role of follower


This is inaccurate.  TLOG can become leader.  If that happens, then it 
functions exactly like an NRT leader.


I'm aware that saying the following is bikeshedding ... but I do think 
it would be as mistake to use any existing SolrCloud terminology for 
non-cloud deployments, including the word "replica".  The top contenders 
I have seen to replace master/slave in Solr are primary/secondary and 
publisher/subscriber.


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.


Thanks,
Shawn

Re: Getting rid of Master/Slave nomenclature in Solr

[Walter Underwood]

Master/slave is not just two roles, but a kind of cluster. I really don’t think
“Standalone” captures the non-Cloud cluster. Nobody in Chegg would 
have any idea that “standalone” meant “no Zookeeper”.

I’ve never thought that master/slave accurately described the traditional
replication model, but I can’t remember what terms I preferred because 
that was ten years ago. A master gives commands. That isn’t how Solr
masters work. It is closer to how an NRT or TLOG leader works, actually.

A Solr master just sits there and waits for other nodes to copy the index.

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

> On Jun 17, 2020, at 3:03 PM, Trey Grainger  wrote:
> 
> Hi Walter,
> 
>> In Solr Cloud, the leader knows about each follower and updates them.
> Respectfully, I think you're mixing the "TYPE" of replica with the role of
> the "leader" and "follower"
> 
> In SolrCloud, only if the TYPE of a follower is NRT or TLOG does the leader
> push updates those followers.
> 
> When the TYPE of a follower is PULL, then it does not.  In Standalone mode,
> the type of a (currently) master would be NRT, and the type of the
> (currently) slaves is always PULL.
> 
> As such, this behavior is consistent across both SolrCloud and Standalone
> mode. It is true that Standalone mode does not currently have support for
> two of the replica TYPES that SolrCloud mode does, but I maintain that
> leader vs. follower behavior is inconsistent here.
> 
> Trey Grainger
> Founder, Searchkernel
> https://searchkernel.com
> 
> 
> 
> On Wed, Jun 17, 2020 at 5:41 PM Walter Underwood 
> wrote:
> 
>> But they are not the same. In Solr Cloud, the leader knows about each
>> follower and updates them. In standalone, the master has no idea that
>> slaves exist until a replication request arrives.
>> 
>> In Solr Cloud, the leader is elected. In standalone, that role is fixed at
>> config load time.
>> 
>> Looking ahead in my email inbox, publisher/subscriber is an excellent
>> choice.
>> 
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>> 
>>> On Jun 17, 2020, at 2:21 PM, Trey Grainger  wrote:
>>> 
>>> I guess I don't see it as polysemous, but instead simplifying.
>>> 
>>> In my proposal, the terms "leader" and "follower" would have the exact
>> same
>>> meaning in both SolrCloud and standalone mode. The only difference would
>> be
>>> that SolrCloud automatically manages the leaders and followers, whereas
>> in
>>> standalone mode you have to manage them manually (as is the case with
>> most
>>> things in SolrCloud vs. Standalone).
>>> 
>>> My view is that having an entirely different set of terminology
>> describing
>>> the same thing is way more cognitive overhead than having consistent
>>> terminology.
>>> 
>>> Trey Grainger
>>> Founder, Searchkernel
>>> https://searchkernel.com
>>> 
>>> On Wed, Jun 17, 2020 at 4:50 PM Walter Underwood 
>>> wrote:
>>> 
 I strongly disagree with using the Solr Cloud leader/follower
>> terminology
 for non-Cloud clusters. People in my company are confused enough without
 using polysemous terminology.
 
 “This node is the leader, but it means something different than the
>> leader
 in this other cluster.” I’m dreading that conversation.
 
 I like “principal”. How about “clone” for the slave role? That suggests
 that
 it does not accept updates and that it is loosely-coupled, only
>> depending
 on the state of the no-longer-called-master.
 
 Chegg has five production Solr Cloud clusters and one production
 master/slave
 cluster, so this is not a hypothetical for us. We have 100+ Solr hosts
>> in
 production.
 
 wunder
 Walter Underwood
 wun...@wunderwood.org
 http://observer.wunderwood.org/  (my blog)
 
> On Jun 17, 2020, at 1:36 PM, Trey Grainger  wrote:
> 
> Proposal:
> "A Solr COLLECTION is composed of one or more SHARDS, which each have
>> one
> or more REPLICAS. Each replica can have a ROLE of either:
> 1) A LEADER, which can process external updates for the shard
> 2) A FOLLOWER, which receives updates from another replica"
> 
> (Note: I prefer "role" but if others think it's too overloaded due to
>> the
> overseer role, we could replace it with "mode" or something similar)
> ---
> 
> To be explicit with the above definitions:
> 1) In SolrCloud, the roles of leaders and followers can dynamically
 change
> based upon the status of the cluster. In standalone mode, they can be
> changed by manual intervention.
> 2) A leader does not have to have any followers (i.e. only one active
> replica)
> 3) Each shard always has one leader.
> 4) A follower can also pull updates from another follower instead of a
> leader (traditionally known as a REPEATER). A repeater is still a
 follower,
> but would 

Re: Getting rid of Master/Slave nomenclature in Solr

[Trey Grainger]

Sorry:
>
> but I maintain that leader vs. follower behavior is inconsistent here.


Sorry, that should have said "I maintain that leader vs. follower behavior
is consistent here."

Trey Grainger
Founder, Searchkernel
https://searchkernel.com

On Wed, Jun 17, 2020 at 6:03 PM Trey Grainger  wrote:

> Hi Walter,
>
> >In Solr Cloud, the leader knows about each follower and updates them.
> Respectfully, I think you're mixing the "TYPE" of replica with the role of
> the "leader" and "follower"
>
> In SolrCloud, only if the TYPE of a follower is NRT or TLOG does the
> leader push updates those followers.
>
> When the TYPE of a follower is PULL, then it does not.  In Standalone
> mode, the type of a (currently) master would be NRT, and the type of the
> (currently) slaves is always PULL.
>
> As such, this behavior is consistent across both SolrCloud and Standalone
> mode. It is true that Standalone mode does not currently have support for
> two of the replica TYPES that SolrCloud mode does, but I maintain that
> leader vs. follower behavior is inconsistent here.
>
> Trey Grainger
> Founder, Searchkernel
> https://searchkernel.com
>
>
>
> On Wed, Jun 17, 2020 at 5:41 PM Walter Underwood 
> wrote:
>
>> But they are not the same. In Solr Cloud, the leader knows about each
>> follower and updates them. In standalone, the master has no idea that
>> slaves exist until a replication request arrives.
>>
>> In Solr Cloud, the leader is elected. In standalone, that role is fixed at
>> config load time.
>>
>> Looking ahead in my email inbox, publisher/subscriber is an excellent
>> choice.
>>
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>>
>> > On Jun 17, 2020, at 2:21 PM, Trey Grainger  wrote:
>> >
>> > I guess I don't see it as polysemous, but instead simplifying.
>> >
>> > In my proposal, the terms "leader" and "follower" would have the exact
>> same
>> > meaning in both SolrCloud and standalone mode. The only difference
>> would be
>> > that SolrCloud automatically manages the leaders and followers, whereas
>> in
>> > standalone mode you have to manage them manually (as is the case with
>> most
>> > things in SolrCloud vs. Standalone).
>> >
>> > My view is that having an entirely different set of terminology
>> describing
>> > the same thing is way more cognitive overhead than having consistent
>> > terminology.
>> >
>> > Trey Grainger
>> > Founder, Searchkernel
>> > https://searchkernel.com
>> >
>> > On Wed, Jun 17, 2020 at 4:50 PM Walter Underwood > >
>> > wrote:
>> >
>> >> I strongly disagree with using the Solr Cloud leader/follower
>> terminology
>> >> for non-Cloud clusters. People in my company are confused enough
>> without
>> >> using polysemous terminology.
>> >>
>> >> “This node is the leader, but it means something different than the
>> leader
>> >> in this other cluster.” I’m dreading that conversation.
>> >>
>> >> I like “principal”. How about “clone” for the slave role? That suggests
>> >> that
>> >> it does not accept updates and that it is loosely-coupled, only
>> depending
>> >> on the state of the no-longer-called-master.
>> >>
>> >> Chegg has five production Solr Cloud clusters and one production
>> >> master/slave
>> >> cluster, so this is not a hypothetical for us. We have 100+ Solr hosts
>> in
>> >> production.
>> >>
>> >> wunder
>> >> Walter Underwood
>> >> wun...@wunderwood.org
>> >> http://observer.wunderwood.org/  (my blog)
>> >>
>> >>> On Jun 17, 2020, at 1:36 PM, Trey Grainger 
>> wrote:
>> >>>
>> >>> Proposal:
>> >>> "A Solr COLLECTION is composed of one or more SHARDS, which each have
>> one
>> >>> or more REPLICAS. Each replica can have a ROLE of either:
>> >>> 1) A LEADER, which can process external updates for the shard
>> >>> 2) A FOLLOWER, which receives updates from another replica"
>> >>>
>> >>> (Note: I prefer "role" but if others think it's too overloaded due to
>> the
>> >>> overseer role, we could replace it with "mode" or something similar)
>> >>> ---
>> >>>
>> >>> To be explicit with the above definitions:
>> >>> 1) In SolrCloud, the roles of leaders and followers can dynamically
>> >> change
>> >>> based upon the status of the cluster. In standalone mode, they can be
>> >>> changed by manual intervention.
>> >>> 2) A leader does not have to have any followers (i.e. only one active
>> >>> replica)
>> >>> 3) Each shard always has one leader.
>> >>> 4) A follower can also pull updates from another follower instead of a
>> >>> leader (traditionally known as a REPEATER). A repeater is still a
>> >> follower,
>> >>> but would not be considered a leader because it can't process external
>> >>> updates.
>> >>> 5) A replica cannot be both a leader and a follower.
>> >>>
>> >>> In addition to the above roles, each replica can have a TYPE of one
>> of:
>> >>> 1) NRT - which can serve in the role of leader or follower
>> >>> 2) TLOG - which can only serve in the role of follower
>> >>> 3) PULL 

Re: Getting rid of Master/Slave nomenclature in Solr

[Trey Grainger]

Hi Walter,

>In Solr Cloud, the leader knows about each follower and updates them.
Respectfully, I think you're mixing the "TYPE" of replica with the role of
the "leader" and "follower"

In SolrCloud, only if the TYPE of a follower is NRT or TLOG does the leader
push updates those followers.

When the TYPE of a follower is PULL, then it does not.  In Standalone mode,
the type of a (currently) master would be NRT, and the type of the
(currently) slaves is always PULL.

As such, this behavior is consistent across both SolrCloud and Standalone
mode. It is true that Standalone mode does not currently have support for
two of the replica TYPES that SolrCloud mode does, but I maintain that
leader vs. follower behavior is inconsistent here.

Trey Grainger
Founder, Searchkernel
https://searchkernel.com



On Wed, Jun 17, 2020 at 5:41 PM Walter Underwood 
wrote:

> But they are not the same. In Solr Cloud, the leader knows about each
> follower and updates them. In standalone, the master has no idea that
> slaves exist until a replication request arrives.
>
> In Solr Cloud, the leader is elected. In standalone, that role is fixed at
> config load time.
>
> Looking ahead in my email inbox, publisher/subscriber is an excellent
> choice.
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
> > On Jun 17, 2020, at 2:21 PM, Trey Grainger  wrote:
> >
> > I guess I don't see it as polysemous, but instead simplifying.
> >
> > In my proposal, the terms "leader" and "follower" would have the exact
> same
> > meaning in both SolrCloud and standalone mode. The only difference would
> be
> > that SolrCloud automatically manages the leaders and followers, whereas
> in
> > standalone mode you have to manage them manually (as is the case with
> most
> > things in SolrCloud vs. Standalone).
> >
> > My view is that having an entirely different set of terminology
> describing
> > the same thing is way more cognitive overhead than having consistent
> > terminology.
> >
> > Trey Grainger
> > Founder, Searchkernel
> > https://searchkernel.com
> >
> > On Wed, Jun 17, 2020 at 4:50 PM Walter Underwood 
> > wrote:
> >
> >> I strongly disagree with using the Solr Cloud leader/follower
> terminology
> >> for non-Cloud clusters. People in my company are confused enough without
> >> using polysemous terminology.
> >>
> >> “This node is the leader, but it means something different than the
> leader
> >> in this other cluster.” I’m dreading that conversation.
> >>
> >> I like “principal”. How about “clone” for the slave role? That suggests
> >> that
> >> it does not accept updates and that it is loosely-coupled, only
> depending
> >> on the state of the no-longer-called-master.
> >>
> >> Chegg has five production Solr Cloud clusters and one production
> >> master/slave
> >> cluster, so this is not a hypothetical for us. We have 100+ Solr hosts
> in
> >> production.
> >>
> >> wunder
> >> Walter Underwood
> >> wun...@wunderwood.org
> >> http://observer.wunderwood.org/  (my blog)
> >>
> >>> On Jun 17, 2020, at 1:36 PM, Trey Grainger  wrote:
> >>>
> >>> Proposal:
> >>> "A Solr COLLECTION is composed of one or more SHARDS, which each have
> one
> >>> or more REPLICAS. Each replica can have a ROLE of either:
> >>> 1) A LEADER, which can process external updates for the shard
> >>> 2) A FOLLOWER, which receives updates from another replica"
> >>>
> >>> (Note: I prefer "role" but if others think it's too overloaded due to
> the
> >>> overseer role, we could replace it with "mode" or something similar)
> >>> ---
> >>>
> >>> To be explicit with the above definitions:
> >>> 1) In SolrCloud, the roles of leaders and followers can dynamically
> >> change
> >>> based upon the status of the cluster. In standalone mode, they can be
> >>> changed by manual intervention.
> >>> 2) A leader does not have to have any followers (i.e. only one active
> >>> replica)
> >>> 3) Each shard always has one leader.
> >>> 4) A follower can also pull updates from another follower instead of a
> >>> leader (traditionally known as a REPEATER). A repeater is still a
> >> follower,
> >>> but would not be considered a leader because it can't process external
> >>> updates.
> >>> 5) A replica cannot be both a leader and a follower.
> >>>
> >>> In addition to the above roles, each replica can have a TYPE of one of:
> >>> 1) NRT - which can serve in the role of leader or follower
> >>> 2) TLOG - which can only serve in the role of follower
> >>> 3) PULL - which can only serve in the role of follower
> >>>
> >>> A replica's type may be changed automatically in the event that its
> role
> >>> changes.
> >>>
> >>> I think this terminology is consistent with the current Leader/Follower
> >>> usage while also being able to easily accomodate a rename of the
> >> historical
> >>> master/slave terminology without mental gymnastics or the introduction
> or
> >>> more cognitive load through new terminology. I 

Re: Getting rid of Master/Slave nomenclature in Solr

[Sameer Maggon]

+1 for simplifying and using the Leader/Follower Terminology. Our company
operates both SolrCloud, Standalone Solr, and Master/Slave Configurations,
outside of the Solr Developer community, it's painful and confusing to talk
about Master/Slave and Leader/Replica. It would be easier if we had the
following:

The internal differences between manual configuration or SolrCloud being
smart about managing and assigning roles are just the evolution of the
design and details of a particular mode/implementation and shouldn't matter
to the end-user.

Today, when someone not involved in the Solr development looks at the
terminology, it looks new terminology is introduced without thinking about
existing customers or thinking through the system as a whole and how to
best evolve it (not saying that's what happened, but just a perception).
Adding new terminology should be introduced carefully and +1 on reducing
the cognitive load on an average guy like me.

- There are leaders and there are followers
- Solr Clusters can be configured in two modes/implementation (SolrCloud or
Master/Slave). This one is hard because you don't want to introduce yet
another name here as people are now already familiar with it.
- These modes happen to have different designs and depending upon the mode,
you can go into the design differences of these two modes.

Cheers!
-- 

*Sameer Maggon*
*SearchStax* | www.searchstax.com


On Wed, Jun 17, 2020 at 2:22 PM gnandre  wrote:

> +1 for Leader-Follower. How about Publisher-Subscriber?
>
> On Wed, Jun 17, 2020 at 5:19 PM Rahul Goswami 
> wrote:
>
> > +1 on avoiding SolrCloud terminology. In the interest of keeping it
> obvious
> > and simple, may I I please suggest primary/secondary?
> >
> > On Wed, Jun 17, 2020 at 5:14 PM Atita Arora 
> wrote:
> >
> > > I agree avoiding using of solr cloud terminology too.
> > >
> > > I may suggest going for "prime" and "clone"
> > > (Short and precise as Master and Slave).
> > >
> > > Best,
> > > Atita
> > >
> > >
> > >
> > >
> > >
> > > On Wed, 17 Jun 2020, 22:50 Walter Underwood, 
> > > wrote:
> > >
> > > > I strongly disagree with using the Solr Cloud leader/follower
> > terminology
> > > > for non-Cloud clusters. People in my company are confused enough
> > without
> > > > using polysemous terminology.
> > > >
> > > > “This node is the leader, but it means something different than the
> > > leader
> > > > in this other cluster.” I’m dreading that conversation.
> > > >
> > > > I like “principal”. How about “clone” for the slave role? That
> suggests
> > > > that
> > > > it does not accept updates and that it is loosely-coupled, only
> > depending
> > > > on the state of the no-longer-called-master.
> > > >
> > > > Chegg has five production Solr Cloud clusters and one production
> > > > master/slave
> > > > cluster, so this is not a hypothetical for us. We have 100+ Solr
> hosts
> > in
> > > > production.
> > > >
> > > > wunder
> > > > Walter Underwood
> > > > wun...@wunderwood.org
> > > > http://observer.wunderwood.org/  (my blog)
> > > >
> > > > > On Jun 17, 2020, at 1:36 PM, Trey Grainger 
> > wrote:
> > > > >
> > > > > Proposal:
> > > > > "A Solr COLLECTION is composed of one or more SHARDS, which each
> have
> > > one
> > > > > or more REPLICAS. Each replica can have a ROLE of either:
> > > > > 1) A LEADER, which can process external updates for the shard
> > > > > 2) A FOLLOWER, which receives updates from another replica"
> > > > >
> > > > > (Note: I prefer "role" but if others think it's too overloaded due
> to
> > > the
> > > > > overseer role, we could replace it with "mode" or something
> similar)
> > > > > ---
> > > > >
> > > > > To be explicit with the above definitions:
> > > > > 1) In SolrCloud, the roles of leaders and followers can dynamically
> > > > change
> > > > > based upon the status of the cluster. In standalone mode, they can
> be
> > > > > changed by manual intervention.
> > > > > 2) A leader does not have to have any followers (i.e. only one
> active
> > > > > replica)
> > > > > 3) Each shard always has one leader.
> > > > > 4) A follower can also pull updates from another follower instead
> of
> > a
> > > > > leader (traditionally known as a REPEATER). A repeater is still a
> > > > follower,
> > > > > but would not be considered a leader because it can't process
> > external
> > > > > updates.
> > > > > 5) A replica cannot be both a leader and a follower.
> > > > >
> > > > > In addition to the above roles, each replica can have a TYPE of one
> > of:
> > > > > 1) NRT - which can serve in the role of leader or follower
> > > > > 2) TLOG - which can only serve in the role of follower
> > > > > 3) PULL - which can only serve in the role of follower
> > > > >
> > > > > A replica's type may be changed automatically in the event that its
> > > role
> > > > > changes.
> > > > >
> > > > > I think this terminology is consistent with the current
> > Leader/Follower
> > > > > usage while also being able 

Re: Getting rid of Master/Slave nomenclature in Solr

[Walter Underwood]

But they are not the same. In Solr Cloud, the leader knows about each
follower and updates them. In standalone, the master has no idea that
slaves exist until a replication request arrives.

In Solr Cloud, the leader is elected. In standalone, that role is fixed at
config load time.

Looking ahead in my email inbox, publisher/subscriber is an excellent choice.

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

> On Jun 17, 2020, at 2:21 PM, Trey Grainger  wrote:
> 
> I guess I don't see it as polysemous, but instead simplifying.
> 
> In my proposal, the terms "leader" and "follower" would have the exact same
> meaning in both SolrCloud and standalone mode. The only difference would be
> that SolrCloud automatically manages the leaders and followers, whereas in
> standalone mode you have to manage them manually (as is the case with most
> things in SolrCloud vs. Standalone).
> 
> My view is that having an entirely different set of terminology describing
> the same thing is way more cognitive overhead than having consistent
> terminology.
> 
> Trey Grainger
> Founder, Searchkernel
> https://searchkernel.com
> 
> On Wed, Jun 17, 2020 at 4:50 PM Walter Underwood 
> wrote:
> 
>> I strongly disagree with using the Solr Cloud leader/follower terminology
>> for non-Cloud clusters. People in my company are confused enough without
>> using polysemous terminology.
>> 
>> “This node is the leader, but it means something different than the leader
>> in this other cluster.” I’m dreading that conversation.
>> 
>> I like “principal”. How about “clone” for the slave role? That suggests
>> that
>> it does not accept updates and that it is loosely-coupled, only depending
>> on the state of the no-longer-called-master.
>> 
>> Chegg has five production Solr Cloud clusters and one production
>> master/slave
>> cluster, so this is not a hypothetical for us. We have 100+ Solr hosts in
>> production.
>> 
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>> 
>>> On Jun 17, 2020, at 1:36 PM, Trey Grainger  wrote:
>>> 
>>> Proposal:
>>> "A Solr COLLECTION is composed of one or more SHARDS, which each have one
>>> or more REPLICAS. Each replica can have a ROLE of either:
>>> 1) A LEADER, which can process external updates for the shard
>>> 2) A FOLLOWER, which receives updates from another replica"
>>> 
>>> (Note: I prefer "role" but if others think it's too overloaded due to the
>>> overseer role, we could replace it with "mode" or something similar)
>>> ---
>>> 
>>> To be explicit with the above definitions:
>>> 1) In SolrCloud, the roles of leaders and followers can dynamically
>> change
>>> based upon the status of the cluster. In standalone mode, they can be
>>> changed by manual intervention.
>>> 2) A leader does not have to have any followers (i.e. only one active
>>> replica)
>>> 3) Each shard always has one leader.
>>> 4) A follower can also pull updates from another follower instead of a
>>> leader (traditionally known as a REPEATER). A repeater is still a
>> follower,
>>> but would not be considered a leader because it can't process external
>>> updates.
>>> 5) A replica cannot be both a leader and a follower.
>>> 
>>> In addition to the above roles, each replica can have a TYPE of one of:
>>> 1) NRT - which can serve in the role of leader or follower
>>> 2) TLOG - which can only serve in the role of follower
>>> 3) PULL - which can only serve in the role of follower
>>> 
>>> A replica's type may be changed automatically in the event that its role
>>> changes.
>>> 
>>> I think this terminology is consistent with the current Leader/Follower
>>> usage while also being able to easily accomodate a rename of the
>> historical
>>> master/slave terminology without mental gymnastics or the introduction or
>>> more cognitive load through new terminology. I think adopting the
>>> Primary/Replica terminology will be incredibly confusing given the
>> already
>>> specific and well established meaning of "replica" within Solr.
>>> 
>>> All the Best,
>>> 
>>> Trey Grainger
>>> Founder, Searchkernel
>>> https://searchkernel.com
>>> 
>>> 
>>> 
>>> On Wed, Jun 17, 2020 at 3:38 PM Anshum Gupta 
>> wrote:
>>> 
 Hi everyone,
 
 Moving a conversation that was happening on the PMC list to the public
 forum. Most of the following is just me recapping the conversation that
>> has
 happened so far.
 
 Some members of the community have been discussing getting rid of the
 master/slave nomenclature from Solr.
 
 While this may require a non-trivial effort, a general consensus so far
 seems to be to start this process and switch over incrementally, if a
 single change ends up being too big.
 
 There have been a lot of suggestions around what the new nomenclature
>> might
 look like, a few people don’t want to overlap the naming here with what
 already exists 

Re: Getting rid of Master/Slave nomenclature in Solr

[gnandre]

+1 for Leader-Follower. How about Publisher-Subscriber?

On Wed, Jun 17, 2020 at 5:19 PM Rahul Goswami  wrote:

> +1 on avoiding SolrCloud terminology. In the interest of keeping it obvious
> and simple, may I I please suggest primary/secondary?
>
> On Wed, Jun 17, 2020 at 5:14 PM Atita Arora  wrote:
>
> > I agree avoiding using of solr cloud terminology too.
> >
> > I may suggest going for "prime" and "clone"
> > (Short and precise as Master and Slave).
> >
> > Best,
> > Atita
> >
> >
> >
> >
> >
> > On Wed, 17 Jun 2020, 22:50 Walter Underwood, 
> > wrote:
> >
> > > I strongly disagree with using the Solr Cloud leader/follower
> terminology
> > > for non-Cloud clusters. People in my company are confused enough
> without
> > > using polysemous terminology.
> > >
> > > “This node is the leader, but it means something different than the
> > leader
> > > in this other cluster.” I’m dreading that conversation.
> > >
> > > I like “principal”. How about “clone” for the slave role? That suggests
> > > that
> > > it does not accept updates and that it is loosely-coupled, only
> depending
> > > on the state of the no-longer-called-master.
> > >
> > > Chegg has five production Solr Cloud clusters and one production
> > > master/slave
> > > cluster, so this is not a hypothetical for us. We have 100+ Solr hosts
> in
> > > production.
> > >
> > > wunder
> > > Walter Underwood
> > > wun...@wunderwood.org
> > > http://observer.wunderwood.org/  (my blog)
> > >
> > > > On Jun 17, 2020, at 1:36 PM, Trey Grainger 
> wrote:
> > > >
> > > > Proposal:
> > > > "A Solr COLLECTION is composed of one or more SHARDS, which each have
> > one
> > > > or more REPLICAS. Each replica can have a ROLE of either:
> > > > 1) A LEADER, which can process external updates for the shard
> > > > 2) A FOLLOWER, which receives updates from another replica"
> > > >
> > > > (Note: I prefer "role" but if others think it's too overloaded due to
> > the
> > > > overseer role, we could replace it with "mode" or something similar)
> > > > ---
> > > >
> > > > To be explicit with the above definitions:
> > > > 1) In SolrCloud, the roles of leaders and followers can dynamically
> > > change
> > > > based upon the status of the cluster. In standalone mode, they can be
> > > > changed by manual intervention.
> > > > 2) A leader does not have to have any followers (i.e. only one active
> > > > replica)
> > > > 3) Each shard always has one leader.
> > > > 4) A follower can also pull updates from another follower instead of
> a
> > > > leader (traditionally known as a REPEATER). A repeater is still a
> > > follower,
> > > > but would not be considered a leader because it can't process
> external
> > > > updates.
> > > > 5) A replica cannot be both a leader and a follower.
> > > >
> > > > In addition to the above roles, each replica can have a TYPE of one
> of:
> > > > 1) NRT - which can serve in the role of leader or follower
> > > > 2) TLOG - which can only serve in the role of follower
> > > > 3) PULL - which can only serve in the role of follower
> > > >
> > > > A replica's type may be changed automatically in the event that its
> > role
> > > > changes.
> > > >
> > > > I think this terminology is consistent with the current
> Leader/Follower
> > > > usage while also being able to easily accomodate a rename of the
> > > historical
> > > > master/slave terminology without mental gymnastics or the
> introduction
> > or
> > > > more cognitive load through new terminology. I think adopting the
> > > > Primary/Replica terminology will be incredibly confusing given the
> > > already
> > > > specific and well established meaning of "replica" within Solr.
> > > >
> > > > All the Best,
> > > >
> > > > Trey Grainger
> > > > Founder, Searchkernel
> > > > https://searchkernel.com
> > > >
> > > >
> > > >
> > > > On Wed, Jun 17, 2020 at 3:38 PM Anshum Gupta  >
> > > wrote:
> > > >
> > > >> Hi everyone,
> > > >>
> > > >> Moving a conversation that was happening on the PMC list to the
> public
> > > >> forum. Most of the following is just me recapping the conversation
> > that
> > > has
> > > >> happened so far.
> > > >>
> > > >> Some members of the community have been discussing getting rid of
> the
> > > >> master/slave nomenclature from Solr.
> > > >>
> > > >> While this may require a non-trivial effort, a general consensus so
> > far
> > > >> seems to be to start this process and switch over incrementally, if
> a
> > > >> single change ends up being too big.
> > > >>
> > > >> There have been a lot of suggestions around what the new
> nomenclature
> > > might
> > > >> look like, a few people don’t want to overlap the naming here with
> > what
> > > >> already exists in SolrCloud i.e. leader/follower.
> > > >>
> > > >> Primary/Replica was an option that was suggested based on what other
> > > >> vendors are moving towards based on Wikipedia:
> > > >> https://en.wikipedia.org/wiki/Master/slave_(technology)
> > > >> , however there 

Re: Getting rid of Master/Slave nomenclature in Solr

[Trey Grainger]

I guess I don't see it as polysemous, but instead simplifying.

In my proposal, the terms "leader" and "follower" would have the exact same
meaning in both SolrCloud and standalone mode. The only difference would be
that SolrCloud automatically manages the leaders and followers, whereas in
standalone mode you have to manage them manually (as is the case with most
things in SolrCloud vs. Standalone).

My view is that having an entirely different set of terminology describing
the same thing is way more cognitive overhead than having consistent
terminology.

Trey Grainger
Founder, Searchkernel
https://searchkernel.com

On Wed, Jun 17, 2020 at 4:50 PM Walter Underwood 
wrote:

> I strongly disagree with using the Solr Cloud leader/follower terminology
> for non-Cloud clusters. People in my company are confused enough without
> using polysemous terminology.
>
> “This node is the leader, but it means something different than the leader
> in this other cluster.” I’m dreading that conversation.
>
> I like “principal”. How about “clone” for the slave role? That suggests
> that
> it does not accept updates and that it is loosely-coupled, only depending
> on the state of the no-longer-called-master.
>
> Chegg has five production Solr Cloud clusters and one production
> master/slave
> cluster, so this is not a hypothetical for us. We have 100+ Solr hosts in
> production.
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
> > On Jun 17, 2020, at 1:36 PM, Trey Grainger  wrote:
> >
> > Proposal:
> > "A Solr COLLECTION is composed of one or more SHARDS, which each have one
> > or more REPLICAS. Each replica can have a ROLE of either:
> > 1) A LEADER, which can process external updates for the shard
> > 2) A FOLLOWER, which receives updates from another replica"
> >
> > (Note: I prefer "role" but if others think it's too overloaded due to the
> > overseer role, we could replace it with "mode" or something similar)
> > ---
> >
> > To be explicit with the above definitions:
> > 1) In SolrCloud, the roles of leaders and followers can dynamically
> change
> > based upon the status of the cluster. In standalone mode, they can be
> > changed by manual intervention.
> > 2) A leader does not have to have any followers (i.e. only one active
> > replica)
> > 3) Each shard always has one leader.
> > 4) A follower can also pull updates from another follower instead of a
> > leader (traditionally known as a REPEATER). A repeater is still a
> follower,
> > but would not be considered a leader because it can't process external
> > updates.
> > 5) A replica cannot be both a leader and a follower.
> >
> > In addition to the above roles, each replica can have a TYPE of one of:
> > 1) NRT - which can serve in the role of leader or follower
> > 2) TLOG - which can only serve in the role of follower
> > 3) PULL - which can only serve in the role of follower
> >
> > A replica's type may be changed automatically in the event that its role
> > changes.
> >
> > I think this terminology is consistent with the current Leader/Follower
> > usage while also being able to easily accomodate a rename of the
> historical
> > master/slave terminology without mental gymnastics or the introduction or
> > more cognitive load through new terminology. I think adopting the
> > Primary/Replica terminology will be incredibly confusing given the
> already
> > specific and well established meaning of "replica" within Solr.
> >
> > All the Best,
> >
> > Trey Grainger
> > Founder, Searchkernel
> > https://searchkernel.com
> >
> >
> >
> > On Wed, Jun 17, 2020 at 3:38 PM Anshum Gupta 
> wrote:
> >
> >> Hi everyone,
> >>
> >> Moving a conversation that was happening on the PMC list to the public
> >> forum. Most of the following is just me recapping the conversation that
> has
> >> happened so far.
> >>
> >> Some members of the community have been discussing getting rid of the
> >> master/slave nomenclature from Solr.
> >>
> >> While this may require a non-trivial effort, a general consensus so far
> >> seems to be to start this process and switch over incrementally, if a
> >> single change ends up being too big.
> >>
> >> There have been a lot of suggestions around what the new nomenclature
> might
> >> look like, a few people don’t want to overlap the naming here with what
> >> already exists in SolrCloud i.e. leader/follower.
> >>
> >> Primary/Replica was an option that was suggested based on what other
> >> vendors are moving towards based on Wikipedia:
> >> https://en.wikipedia.org/wiki/Master/slave_(technology)
> >> , however there were concerns around the use of “replica” as that
> denotes a
> >> very specific concept in SolrCloud. Current terminology clearly
> >> differentiates the use of the traditional replication model from
> SolrCloud
> >> and reusing the names would make it difficult for that to happen.
> >>
> >> There were similar concerns around using Leader/follower.

Re: Getting rid of Master/Slave nomenclature in Solr

[Rahul Goswami]

+1 on avoiding SolrCloud terminology. In the interest of keeping it obvious
and simple, may I I please suggest primary/secondary?

On Wed, Jun 17, 2020 at 5:14 PM Atita Arora  wrote:

> I agree avoiding using of solr cloud terminology too.
>
> I may suggest going for "prime" and "clone"
> (Short and precise as Master and Slave).
>
> Best,
> Atita
>
>
>
>
>
> On Wed, 17 Jun 2020, 22:50 Walter Underwood, 
> wrote:
>
> > I strongly disagree with using the Solr Cloud leader/follower terminology
> > for non-Cloud clusters. People in my company are confused enough without
> > using polysemous terminology.
> >
> > “This node is the leader, but it means something different than the
> leader
> > in this other cluster.” I’m dreading that conversation.
> >
> > I like “principal”. How about “clone” for the slave role? That suggests
> > that
> > it does not accept updates and that it is loosely-coupled, only depending
> > on the state of the no-longer-called-master.
> >
> > Chegg has five production Solr Cloud clusters and one production
> > master/slave
> > cluster, so this is not a hypothetical for us. We have 100+ Solr hosts in
> > production.
> >
> > wunder
> > Walter Underwood
> > wun...@wunderwood.org
> > http://observer.wunderwood.org/  (my blog)
> >
> > > On Jun 17, 2020, at 1:36 PM, Trey Grainger  wrote:
> > >
> > > Proposal:
> > > "A Solr COLLECTION is composed of one or more SHARDS, which each have
> one
> > > or more REPLICAS. Each replica can have a ROLE of either:
> > > 1) A LEADER, which can process external updates for the shard
> > > 2) A FOLLOWER, which receives updates from another replica"
> > >
> > > (Note: I prefer "role" but if others think it's too overloaded due to
> the
> > > overseer role, we could replace it with "mode" or something similar)
> > > ---
> > >
> > > To be explicit with the above definitions:
> > > 1) In SolrCloud, the roles of leaders and followers can dynamically
> > change
> > > based upon the status of the cluster. In standalone mode, they can be
> > > changed by manual intervention.
> > > 2) A leader does not have to have any followers (i.e. only one active
> > > replica)
> > > 3) Each shard always has one leader.
> > > 4) A follower can also pull updates from another follower instead of a
> > > leader (traditionally known as a REPEATER). A repeater is still a
> > follower,
> > > but would not be considered a leader because it can't process external
> > > updates.
> > > 5) A replica cannot be both a leader and a follower.
> > >
> > > In addition to the above roles, each replica can have a TYPE of one of:
> > > 1) NRT - which can serve in the role of leader or follower
> > > 2) TLOG - which can only serve in the role of follower
> > > 3) PULL - which can only serve in the role of follower
> > >
> > > A replica's type may be changed automatically in the event that its
> role
> > > changes.
> > >
> > > I think this terminology is consistent with the current Leader/Follower
> > > usage while also being able to easily accomodate a rename of the
> > historical
> > > master/slave terminology without mental gymnastics or the introduction
> or
> > > more cognitive load through new terminology. I think adopting the
> > > Primary/Replica terminology will be incredibly confusing given the
> > already
> > > specific and well established meaning of "replica" within Solr.
> > >
> > > All the Best,
> > >
> > > Trey Grainger
> > > Founder, Searchkernel
> > > https://searchkernel.com
> > >
> > >
> > >
> > > On Wed, Jun 17, 2020 at 3:38 PM Anshum Gupta 
> > wrote:
> > >
> > >> Hi everyone,
> > >>
> > >> Moving a conversation that was happening on the PMC list to the public
> > >> forum. Most of the following is just me recapping the conversation
> that
> > has
> > >> happened so far.
> > >>
> > >> Some members of the community have been discussing getting rid of the
> > >> master/slave nomenclature from Solr.
> > >>
> > >> While this may require a non-trivial effort, a general consensus so
> far
> > >> seems to be to start this process and switch over incrementally, if a
> > >> single change ends up being too big.
> > >>
> > >> There have been a lot of suggestions around what the new nomenclature
> > might
> > >> look like, a few people don’t want to overlap the naming here with
> what
> > >> already exists in SolrCloud i.e. leader/follower.
> > >>
> > >> Primary/Replica was an option that was suggested based on what other
> > >> vendors are moving towards based on Wikipedia:
> > >> https://en.wikipedia.org/wiki/Master/slave_(technology)
> > >> , however there were concerns around the use of “replica” as that
> > denotes a
> > >> very specific concept in SolrCloud. Current terminology clearly
> > >> differentiates the use of the traditional replication model from
> > SolrCloud
> > >> and reusing the names would make it difficult for that to happen.
> > >>
> > >> There were similar concerns around using Leader/follower.
> > >>
> > >> Let’s continue this 

Re: Getting rid of Master/Slave nomenclature in Solr

[Atita Arora]

I agree avoiding using of solr cloud terminology too.

I may suggest going for "prime" and "clone"
(Short and precise as Master and Slave).

Best,
Atita





On Wed, 17 Jun 2020, 22:50 Walter Underwood,  wrote:

> I strongly disagree with using the Solr Cloud leader/follower terminology
> for non-Cloud clusters. People in my company are confused enough without
> using polysemous terminology.
>
> “This node is the leader, but it means something different than the leader
> in this other cluster.” I’m dreading that conversation.
>
> I like “principal”. How about “clone” for the slave role? That suggests
> that
> it does not accept updates and that it is loosely-coupled, only depending
> on the state of the no-longer-called-master.
>
> Chegg has five production Solr Cloud clusters and one production
> master/slave
> cluster, so this is not a hypothetical for us. We have 100+ Solr hosts in
> production.
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
> > On Jun 17, 2020, at 1:36 PM, Trey Grainger  wrote:
> >
> > Proposal:
> > "A Solr COLLECTION is composed of one or more SHARDS, which each have one
> > or more REPLICAS. Each replica can have a ROLE of either:
> > 1) A LEADER, which can process external updates for the shard
> > 2) A FOLLOWER, which receives updates from another replica"
> >
> > (Note: I prefer "role" but if others think it's too overloaded due to the
> > overseer role, we could replace it with "mode" or something similar)
> > ---
> >
> > To be explicit with the above definitions:
> > 1) In SolrCloud, the roles of leaders and followers can dynamically
> change
> > based upon the status of the cluster. In standalone mode, they can be
> > changed by manual intervention.
> > 2) A leader does not have to have any followers (i.e. only one active
> > replica)
> > 3) Each shard always has one leader.
> > 4) A follower can also pull updates from another follower instead of a
> > leader (traditionally known as a REPEATER). A repeater is still a
> follower,
> > but would not be considered a leader because it can't process external
> > updates.
> > 5) A replica cannot be both a leader and a follower.
> >
> > In addition to the above roles, each replica can have a TYPE of one of:
> > 1) NRT - which can serve in the role of leader or follower
> > 2) TLOG - which can only serve in the role of follower
> > 3) PULL - which can only serve in the role of follower
> >
> > A replica's type may be changed automatically in the event that its role
> > changes.
> >
> > I think this terminology is consistent with the current Leader/Follower
> > usage while also being able to easily accomodate a rename of the
> historical
> > master/slave terminology without mental gymnastics or the introduction or
> > more cognitive load through new terminology. I think adopting the
> > Primary/Replica terminology will be incredibly confusing given the
> already
> > specific and well established meaning of "replica" within Solr.
> >
> > All the Best,
> >
> > Trey Grainger
> > Founder, Searchkernel
> > https://searchkernel.com
> >
> >
> >
> > On Wed, Jun 17, 2020 at 3:38 PM Anshum Gupta 
> wrote:
> >
> >> Hi everyone,
> >>
> >> Moving a conversation that was happening on the PMC list to the public
> >> forum. Most of the following is just me recapping the conversation that
> has
> >> happened so far.
> >>
> >> Some members of the community have been discussing getting rid of the
> >> master/slave nomenclature from Solr.
> >>
> >> While this may require a non-trivial effort, a general consensus so far
> >> seems to be to start this process and switch over incrementally, if a
> >> single change ends up being too big.
> >>
> >> There have been a lot of suggestions around what the new nomenclature
> might
> >> look like, a few people don’t want to overlap the naming here with what
> >> already exists in SolrCloud i.e. leader/follower.
> >>
> >> Primary/Replica was an option that was suggested based on what other
> >> vendors are moving towards based on Wikipedia:
> >> https://en.wikipedia.org/wiki/Master/slave_(technology)
> >> , however there were concerns around the use of “replica” as that
> denotes a
> >> very specific concept in SolrCloud. Current terminology clearly
> >> differentiates the use of the traditional replication model from
> SolrCloud
> >> and reusing the names would make it difficult for that to happen.
> >>
> >> There were similar concerns around using Leader/follower.
> >>
> >> Let’s continue this conversation here while making sure that we converge
> >> without much bike-shedding.
> >>
> >> -Anshum
> >>
>
>

Re: Getting rid of Master/Slave nomenclature in Solr

[Walter Underwood]

I strongly disagree with using the Solr Cloud leader/follower terminology
for non-Cloud clusters. People in my company are confused enough without
using polysemous terminology.

“This node is the leader, but it means something different than the leader
in this other cluster.” I’m dreading that conversation.

I like “principal”. How about “clone” for the slave role? That suggests that
it does not accept updates and that it is loosely-coupled, only depending 
on the state of the no-longer-called-master.

Chegg has five production Solr Cloud clusters and one production master/slave
cluster, so this is not a hypothetical for us. We have 100+ Solr hosts in 
production.

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

> On Jun 17, 2020, at 1:36 PM, Trey Grainger  wrote:
> 
> Proposal:
> "A Solr COLLECTION is composed of one or more SHARDS, which each have one
> or more REPLICAS. Each replica can have a ROLE of either:
> 1) A LEADER, which can process external updates for the shard
> 2) A FOLLOWER, which receives updates from another replica"
> 
> (Note: I prefer "role" but if others think it's too overloaded due to the
> overseer role, we could replace it with "mode" or something similar)
> ---
> 
> To be explicit with the above definitions:
> 1) In SolrCloud, the roles of leaders and followers can dynamically change
> based upon the status of the cluster. In standalone mode, they can be
> changed by manual intervention.
> 2) A leader does not have to have any followers (i.e. only one active
> replica)
> 3) Each shard always has one leader.
> 4) A follower can also pull updates from another follower instead of a
> leader (traditionally known as a REPEATER). A repeater is still a follower,
> but would not be considered a leader because it can't process external
> updates.
> 5) A replica cannot be both a leader and a follower.
> 
> In addition to the above roles, each replica can have a TYPE of one of:
> 1) NRT - which can serve in the role of leader or follower
> 2) TLOG - which can only serve in the role of follower
> 3) PULL - which can only serve in the role of follower
> 
> A replica's type may be changed automatically in the event that its role
> changes.
> 
> I think this terminology is consistent with the current Leader/Follower
> usage while also being able to easily accomodate a rename of the historical
> master/slave terminology without mental gymnastics or the introduction or
> more cognitive load through new terminology. I think adopting the
> Primary/Replica terminology will be incredibly confusing given the already
> specific and well established meaning of "replica" within Solr.
> 
> All the Best,
> 
> Trey Grainger
> Founder, Searchkernel
> https://searchkernel.com
> 
> 
> 
> On Wed, Jun 17, 2020 at 3:38 PM Anshum Gupta  wrote:
> 
>> Hi everyone,
>> 
>> Moving a conversation that was happening on the PMC list to the public
>> forum. Most of the following is just me recapping the conversation that has
>> happened so far.
>> 
>> Some members of the community have been discussing getting rid of the
>> master/slave nomenclature from Solr.
>> 
>> While this may require a non-trivial effort, a general consensus so far
>> seems to be to start this process and switch over incrementally, if a
>> single change ends up being too big.
>> 
>> There have been a lot of suggestions around what the new nomenclature might
>> look like, a few people don’t want to overlap the naming here with what
>> already exists in SolrCloud i.e. leader/follower.
>> 
>> Primary/Replica was an option that was suggested based on what other
>> vendors are moving towards based on Wikipedia:
>> https://en.wikipedia.org/wiki/Master/slave_(technology)
>> , however there were concerns around the use of “replica” as that denotes a
>> very specific concept in SolrCloud. Current terminology clearly
>> differentiates the use of the traditional replication model from SolrCloud
>> and reusing the names would make it difficult for that to happen.
>> 
>> There were similar concerns around using Leader/follower.
>> 
>> Let’s continue this conversation here while making sure that we converge
>> without much bike-shedding.
>> 
>> -Anshum
>> 

Re: Getting rid of Master/Slave nomenclature in Solr

[Trey Grainger]

Proposal:
"A Solr COLLECTION is composed of one or more SHARDS, which each have one
or more REPLICAS. Each replica can have a ROLE of either:
1) A LEADER, which can process external updates for the shard
2) A FOLLOWER, which receives updates from another replica"

(Note: I prefer "role" but if others think it's too overloaded due to the
overseer role, we could replace it with "mode" or something similar)
---

To be explicit with the above definitions:
1) In SolrCloud, the roles of leaders and followers can dynamically change
based upon the status of the cluster. In standalone mode, they can be
changed by manual intervention.
2) A leader does not have to have any followers (i.e. only one active
replica)
3) Each shard always has one leader.
4) A follower can also pull updates from another follower instead of a
leader (traditionally known as a REPEATER). A repeater is still a follower,
but would not be considered a leader because it can't process external
updates.
5) A replica cannot be both a leader and a follower.

In addition to the above roles, each replica can have a TYPE of one of:
1) NRT - which can serve in the role of leader or follower
2) TLOG - which can only serve in the role of follower
3) PULL - which can only serve in the role of follower

A replica's type may be changed automatically in the event that its role
changes.

I think this terminology is consistent with the current Leader/Follower
usage while also being able to easily accomodate a rename of the historical
master/slave terminology without mental gymnastics or the introduction or
more cognitive load through new terminology. I think adopting the
Primary/Replica terminology will be incredibly confusing given the already
specific and well established meaning of "replica" within Solr.

All the Best,

Trey Grainger
Founder, Searchkernel
https://searchkernel.com



On Wed, Jun 17, 2020 at 3:38 PM Anshum Gupta  wrote:

> Hi everyone,
>
> Moving a conversation that was happening on the PMC list to the public
> forum. Most of the following is just me recapping the conversation that has
> happened so far.
>
> Some members of the community have been discussing getting rid of the
> master/slave nomenclature from Solr.
>
> While this may require a non-trivial effort, a general consensus so far
> seems to be to start this process and switch over incrementally, if a
> single change ends up being too big.
>
> There have been a lot of suggestions around what the new nomenclature might
> look like, a few people don’t want to overlap the naming here with what
> already exists in SolrCloud i.e. leader/follower.
>
> Primary/Replica was an option that was suggested based on what other
> vendors are moving towards based on Wikipedia:
> https://en.wikipedia.org/wiki/Master/slave_(technology)
> , however there were concerns around the use of “replica” as that denotes a
> very specific concept in SolrCloud. Current terminology clearly
> differentiates the use of the traditional replication model from SolrCloud
> and reusing the names would make it difficult for that to happen.
>
> There were similar concerns around using Leader/follower.
>
> Let’s continue this conversation here while making sure that we converge
> without much bike-shedding.
>
> -Anshum
>

Getting rid of Master/Slave nomenclature in Solr

[Anshum Gupta]

Hi everyone,

Moving a conversation that was happening on the PMC list to the public
forum. Most of the following is just me recapping the conversation that has
happened so far.

Some members of the community have been discussing getting rid of the
master/slave nomenclature from Solr.

While this may require a non-trivial effort, a general consensus so far
seems to be to start this process and switch over incrementally, if a
single change ends up being too big.

There have been a lot of suggestions around what the new nomenclature might
look like, a few people don’t want to overlap the naming here with what
already exists in SolrCloud i.e. leader/follower.

Primary/Replica was an option that was suggested based on what other
vendors are moving towards based on Wikipedia:
https://en.wikipedia.org/wiki/Master/slave_(technology)
, however there were concerns around the use of “replica” as that denotes a
very specific concept in SolrCloud. Current terminology clearly
differentiates the use of the traditional replication model from SolrCloud
and reusing the names would make it difficult for that to happen.

There were similar concerns around using Leader/follower.

Let’s continue this conversation here while making sure that we converge
without much bike-shedding.

-Anshum