> > 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.
Yeah, I've typically referred to it as "standalone", but I don't think it's descriptive enough. I can see why some people have been calling it "master/slave" mode in lieu of a more descriptive alternative. I think a new name (other than "standalone" or "legacy") would be superb. 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 +1 SolrCloud is even less descriptive and IMHO just sounds silly at this point. re: "Clustered" vs Independent/Manual. The thing I don't like about that is that you typically have clusters in both modes. I think the key distinction is whether Solr "manages" the cluster automatically for you or whether you manage it manually yourself. What do you think about: Alt E: "Managed Clustering" vs. "Unmanaged Clustering" Mode Alt F: "Managed Clustering" vs. "Manual Clustering" Mode ? I think I prefer option F. Trey Grainger Founder, Searchkernel https://searchkernel.com On Thu, Jun 18, 2020 at 5: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 > >>> > >> > >
