+1 to remove master-slave terminology and favor the proposals that Andrew mentions. This is the right thing to do as community.
Thanks, Esteban. -- Cloudera, Inc. On Mon, Jun 22, 2020 at 4:28 PM Zach York <zyork.contribut...@gmail.com> wrote: > While reading the definitions, I think it is pretty clear that the > definition HBase is intending is somewhere under the #2 definition link. > HMaster is not a teacher (which implies learning on the "student" side), > but rather orders the RS to do a task. > I think master in this context is still worth changing to coordinator since > in my mind this is actually a more clear definition of what HMaster does. > > On Mon, Jun 22, 2020 at 2:09 PM Geoffrey Jacoby <gjac...@apache.org> > wrote: > > > For most of the proposals (slave -> worker, blacklist -> denylist, > > whitelist-> allowlist), I'm +1 (nonbinding). Denylist and acceptlist even > > have the advantage of being clearer than the terms they're replacing. > > > > However, I'm not convinced about changing "master" to "coordinator", or > > something similar. Unlike "slave", which is negative in any context, > > "master" has many definitions, including some common ones which do not > > appear problematic. See > https://www.merriam-webster.com/dictionary/master > > for > > examples. In particular, the progression of an artisan was from > > "apprentice" to "journeyman" to "master". A master smith, carpenter, or > > artist would run a shop managing lots of workers and apprentices who > would > > hope to become masters of their own someday. So "master" and "worker" can > > still go together. > > > > Since it's the least problematic term, and by far the hardest term to > > change (both within HBase and with effects on downstream projects such as > > Ambari), I'm -0 (nonbinding) on changing "master". > > > > Geoffrey > > > > On Mon, Jun 22, 2020 at 1:32 PM Rushabh Shah > > <rushabh.s...@salesforce.com.invalid> wrote: > > > > > +1 to renaming. > > > > > > > > > Rushabh Shah > > > > > > - Software Engineering SMTS | Salesforce > > > - > > > - Mobile: 213 422 9052 > > > > > > > > > > > > On Mon, Jun 22, 2020 at 1:18 PM Josh Elser <els...@apache.org> wrote: > > > > > > > +1 > > > > > > > > On 6/22/20 4:03 PM, Sean Busbey wrote: > > > > > We should change our use of these terms. We can be equally or more > > > clear > > > > in > > > > > what we are trying to convey where they are present. > > > > > > > > > > That they have been used historically is only useful if the > advantage > > > we > > > > > gain from using them through that shared context outweighs the > > > potential > > > > > friction they add. They make me personally less enthusiastic about > > > > > contributing. That's enough friction for me to advocate removing > > them. > > > > > > > > > > AFAICT reworking our replication stuff in terms of "active" and > > > "passive" > > > > > clusters did not result in a big spike of folks asking new > questions > > > > about > > > > > where authority for state was. > > > > > > > > > > On Mon, Jun 22, 2020, 13:39 Andrew Purtell <apurt...@apache.org> > > > wrote: > > > > > > > > > >> In response to renewed attention at the Foundation toward > addressing > > > > >> culturally problematic language and terms often used in technical > > > > >> documentation and discussion, several projects have begun > > discussions, > > > > or > > > > >> made proposals, or started work along these lines. > > > > >> > > > > >> The HBase PMC began its own discussion on private@ on June 9, > 2020 > > > > with an > > > > >> observation of this activity and this suggestion: > > > > >> > > > > >> There is a renewed push back against classic technology industry > > terms > > > > that > > > > >> have negative modern connotations. > > > > >> > > > > >> In the case of HBase, the following substitutions might be > proposed: > > > > >> > > > > >> - Coordinator instead of master > > > > >> > > > > >> - Worker instead of slave > > > > >> > > > > >> Recommendations for these additional substitutions also come up in > > > this > > > > >> type of discussion: > > > > >> > > > > >> - Accept list instead of white list > > > > >> > > > > >> - Deny list instead of black list > > > > >> > > > > >> Unfortunately we have Master all over our code base, baked into > > > various > > > > >> APIs and configuration variable names, so for us the necessary > > changes > > > > >> amount to a new major release and deprecation cycle. It could well > > be > > > > worth > > > > >> it in the long run. We exist only as long as we draw a willing and > > > > >> sufficient contributor community. It also wouldn’t be great to > have > > an > > > > >> activist fork appear somewhere, even if unlikely to be successful. > > > > >> > > > > >> Relevant JIRAs are: > > > > >> > > > > >> - HBASE-12677 < > > https://issues.apache.org/jira/browse/HBASE-12677 > > > >: > > > > >> Update replication docs to clarify terminology > > > > >> - HBASE-13852 < > > https://issues.apache.org/jira/browse/HBASE-13852 > > > >: > > > > >> Replace master-slave terminology in book, site, and javadoc > > with a > > > > more > > > > >> modern vocabulary > > > > >> - HBASE-24576 < > > https://issues.apache.org/jira/browse/HBASE-24576 > > > >: > > > > >> Changing "whitelist" and "blacklist" in our docs and project > > > > >> > > > > >> In response to this proposal, a member of the PMC asked if the > term > > > > >> 'master' used by itself would be fine, because we only have use of > > > > 'slave' > > > > >> in replication documentation and that is easily addressed. In > > response > > > > to > > > > >> this question, others on the PMC suggested that even if only > > 'master' > > > is > > > > >> used, in this context it is still a problem. > > > > >> > > > > >> For folks who are surprised or lacking context on the details of > > this > > > > >> discussion, one PMC member offered a link to this draft RFC as > > > > background: > > > > >> https://tools.ietf.org/id/draft-knodel-terminology-00.html > > > > >> > > > > >> There was general support for removing the term "master" / > "hmaster" > > > > from > > > > >> our code base and using the terms "coordinator" or "leader" > instead. > > > In > > > > the > > > > >> context of replication, "worker" makes less sense and perhaps > > > > "destination" > > > > >> or "follower" would be more appropriate terms. > > > > >> > > > > >> One PMC member's thoughts on language and non-native English > > speakers > > > is > > > > >> worth including in its entirety: > > > > >> > > > > >> While words like blacklist/whitelist/slave clearly have those > > negative > > > > >> references, word master might not have the same impact for non > > native > > > > >> English speakers like myself where the literal translation to my > > > mother > > > > >> tongue does not have this same bad connotation. Replacing all > > > references > > > > >> for word *master *on our docs/codebase is a huge effort, I guess > > such > > > a > > > > >> decision would be more suitable for native English speakers folks, > > and > > > > >> maybe we should consider the opinion of contributors from that > > ethinic > > > > >> minority as well? > > > > >> > > > > >> These are good questions for public discussion. > > > > >> > > > > >> We have a consensus in the PMC, at this time, that is supportive > of > > > > making > > > > >> the above discussed terminology changes. However, we also have > > > concerns > > > > >> about what it would take to accomplish meaningful changes. Several > > on > > > > the > > > > >> PMC offered support in the form of cycles to review pull requests > > and > > > > >> patches, and two PMC members offered personal bandwidth for > > creating > > > > and > > > > >> releasing new code lines as needed to complete a deprecation > cycle. > > > > >> > > > > >> Unfortunately, the terms "master" and "hmaster" appear throughout > > our > > > > code > > > > >> base in class names, user facing API subject to our project > > > > compatibility > > > > >> guidelines, and configuration variable names, which are also > > > implicated > > > > by > > > > >> compatibility guidelines given the impact of changes to operators > > and > > > > >> operations. The changes being discussed are not backwards > compatible > > > > >> changes and cannot be executed with swiftness while simultaneously > > > > >> preserving compatibility. There must be a deprecation cycle. > First, > > we > > > > must > > > > >> tag all implicated public API and configuration variables as > > > deprecated, > > > > >> and release HBase 3 with these deprecations in place. Then, we > must > > > > >> undertake rename and removal as appropriate, and release the > result > > as > > > > >> HBase 4. > > > > >> > > > > >> One PMC member raised a question in this context included here in > > > > entirety: > > > > >> > > > > >> Are we willing to commit to rolling through the major versions at > a > > > pace > > > > >> that's necessary to make this transition as swift as > > > > >> reasonably possible? > > > > >> > > > > >> This is a question for all of us. For the PMC, who would supervise > > the > > > > >> effort, perhaps contribute to it, and certainly vote on the > release > > > > >> candidates. For contributors and potential contributors, who would > > > > provide > > > > >> the necessary patches. For committers, who would be required to > > review > > > > and > > > > >> commit the relevant changes. > > > > >> > > > > >> Although there has been some initial discussion, there is no > > singular > > > > >> proposal, or plan, or set of decisions made at this time. > Wrestling > > > with > > > > >> this concern and the competing concerns involved with addressing > it > > > > >> (motivation for change versus motivation for compatibility) is a > > task > > > > for > > > > >> all of us to undertake (or not) in public on dev@ and user@. > > > > >> > > > > > > > > > > > > > > >
