Another alternative for master-slave nodes might be parent-child nodes. This was adopted in Python too afaik.
On Fri, Jun 19, 2020, 2:07 AM gnandre <arnoldbron...@gmail.com> wrote: > What about blacklist and whitelist for shards? May I suggest blocklist and > safelist? > > On Fri, Jun 19, 2020, 1:45 AM Thomas Corthals <tho...@klascement.net> > wrote: > >> Since "overseer" is also problematic, I'd like to propose "orchestrator" >> as >> an alternative. >> >> Thomas >> >> Op vr 19 jun. 2020 04:34 schreef Walter Underwood <wun...@wunderwood.org >> >: >> >> > 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 <rahul196...@gmail.com> >> > 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 >> > > <sirgilli...@yahoo.com.invalid> 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 <jan....@cominvent.com> >> > 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 <md...@apache.org>: >> > >>>> >> > >>>> 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 >> > >>>> <jgallag...@slack-corp.com.invalid> 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 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 <noble.p...@gmail.com> >> > >>>>>>> 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 >> > >>>>> %2F&data=02%7C01%7Cdemian.katz%40villanova.e >> > >>>>>>>>> >> > >>>>> >> du%7C1eef0604700a442deb7e08d8134b97fb%7C765a8de5cf9444f09cafae5bf8cf >> > >>>>>>>>> >> > >>>>> >> a366%7C0%7C0%7C637280562684672329&sdata=0GyK5Tlq0PGsWxl%2FirJOVN >> > >>>>>>>>> VaFCELlEChdxuLJ5RxdQs%3D&reserved=0 (my blog) >> > >>>>>>>>> >> > >>>>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> -- >> > >>>>>>> ----------------------------------------------------- >> > >>>>>>> Noble Paul >> > >>>>>> >> > >>>>> >> > >>> >> > >> >> > >> >> > >> > >> >
