Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-name Master Components to a more inclusive synonym #6525

Closed
jbpivotal opened this Issue Dec 1, 2017 · 39 comments

Comments

Projects
None yet
@jbpivotal
Copy link

jbpivotal commented Dec 1, 2017

This is a...

  • Feature Request
  • Bug Report

Problem:
The term Master in Master Components is potentially offensive to people of color and women, and I suggest we use a more inclusive synonym.

Proposed Solution:
Suggest renaming to "Primary Components" or "Leader Components"

From cmu.edu:

The word "master", like "mistress", originally meant one
exerting control, as over a household.  "Mistress" is now more
commonly used to mean lover and sometimes teacher.  Master
is now used in a variety of ways, but still largely with the
sense of power and control and, implicitly, maleness.

From django:
replaced occurrences of master/slave terminology with leader/follower

From drupal.org:
Replace "master/slave" terminology with "primary/replica"

Page to Update:
http://kubernetes.io/docs/concepts/overview/components/

@zacharysarah

This comment has been minimized.

Copy link
Contributor

zacharysarah commented Jan 25, 2018

@jbpivotal 👋 Thanks for the proposal and the supporting documentation. I agree that it's a priority change.

/cc @sarahnovotny, @parispittman

@parispittman

This comment has been minimized.

Copy link
Contributor

parispittman commented Jan 25, 2018

I will take this to the next Contributor Experience meeting on Jan 31st at 530pm UTC. We will need to get this in front of the k-dev crowd as well.

Agree with Zach, thanks for bringing this up @jbpivotal!

@ConnorDoyle

This comment has been minimized.

Copy link
Member

ConnorDoyle commented Jan 26, 2018

Another historical point of reference: https://docs.google.com/document/d/1P8_4wdk29I6NoVTjbFkRl05-tfxV9PY4WLoRNvExupM/edit#heading=h.9g7fqjh6652v

Mesos originally had "masters and slaves" and transitioned to "masters and agents". So, "masters" was retained but the most offensive term (according to most who chimed in at the time) was removed.

@jbpivotal

This comment has been minimized.

Copy link
Author

jbpivotal commented Jan 26, 2018

Glad to, @zacharysarah and @parispittman. Thanks for the support.

@idvoretskyi

This comment has been minimized.

Copy link
Member

idvoretskyi commented Jan 26, 2018

"Control Plane" is widely used as an alternative naming for "Master" in Kubernetes, so we may consider this naming option.

@idvoretskyi

This comment has been minimized.

Copy link
Member

idvoretskyi commented Jan 31, 2018

@bgrant0607

This comment has been minimized.

Copy link
Member

bgrant0607 commented Jan 31, 2018

I usually use "control plane".

Minion->node rename:
kubernetes/kubernetes#1111

@bgrant0607

This comment has been minimized.

Copy link
Member

bgrant0607 commented Jan 31, 2018

@jbeda

This comment has been minimized.

Copy link
Contributor

jbeda commented Jan 31, 2018

I like control plane a lot also. But I think that this is going to be a long effort and I'd love to get more perspectives from around the project. This came up in ContribX and the plan was to talk about it a bit in SIG-architecture.

@timothysc

This comment has been minimized.

Copy link
Member

timothysc commented Jan 31, 2018

I'm not opposed to this, but someone needs to drive all the touchpoints to make this change which may be non-trivial. Distributed systems literature is clearly the source here and it goes back 30+ years, not justifying it, but taxonomy refs do matter. If we change it, it should match other literature.

@smarterclayton

This comment has been minimized.

Copy link
Contributor

smarterclayton commented Feb 1, 2018

I'm generally ok with "control plane", master is too imprecise anyway.

@smarterclayton

This comment has been minimized.

Copy link
Contributor

smarterclayton commented Feb 1, 2018

To tie this back to a general problem we have had - we don't have a single component that controls everything else, we don't have a single set of machines. Instead we have "run levels" (an emerging way of describing that various core components depend on other core components being set first), and we need to separate out the things that are monolithic into individual pieces.

@jbeda

This comment has been minimized.

Copy link
Contributor

jbeda commented Feb 1, 2018

The thinking coming out of SIG-architecture:

  1. As @smarterclayton mentions, master isn't a great term from a technical point of view. It isn't a concept that really exists in the core system. Moving to more accurate/descriptive language here will help people communicate more effectively.
  2. It is worthwhile to move away from the term "master" but this will be a long process. Our primary goal initially is to "stop digging a hole" and make sure that going forward we use new language.
  3. We can open issues and make this a "help wanted" type of thing as we create incentives over time to change the name.

Complicating this is that pretty much every github link has the word "master" in it so simply grepping the code base is somewhat difficult.

Also, the preferred replacement seems to be either "control plane" or a more specific aspect of the control plane as appropriate (API server, etcd, etc). But that term isn't final. We want to socialize this at the community meeting.

@tpepper

This comment has been minimized.

Copy link

tpepper commented Feb 1, 2018

The github links with "master" next to them can be greppable with some exclusion as they're preceded by "tree/", "blob/", "raw/", etc. We should be able to define and share a solid regexp that trims out those git links for helper folks searching for areas to clean.

@bgrant0607

This comment has been minimized.

Copy link
Member

bgrant0607 commented Feb 1, 2018

Examples of more specific/precise things we will need terms for:

  • cluster control plane
  • nucleus apiserver
  • dedicated infrastructure nodes
@jfoy

This comment has been minimized.

Copy link

jfoy commented Feb 1, 2018

In our environment we refer to members of the control plane as Controllers and other nodes as Workers. "Controller" is an overloaded term here, so probably not ideal to adopt more widely, but Coordinators, Centers, or Orchestrators might work.

Edit to add: Captains?

@omkensey

This comment has been minimized.

Copy link

omkensey commented Feb 1, 2018

I don't like "leader" only because (and this may be just my skew on it) to me that implies a node elected by a pool of nodes to do something, as in etcd.

"Control plane" seems a little unwieldy to me, as do the various polysyllabic terms like "coordinator".

I like "controller" best since that's a term people already recognize and is used for an analogous machine role in e.g. Active Directory. Yes, it's slightly overloaded in this project, but context would help a lot. I'm hard-pressed to come up with a situation where "controller" is a) ambiguous b) in a context where it matters that c) isn't easily fixed with minor rewording.

@danderson

This comment has been minimized.

Copy link

danderson commented Feb 1, 2018

For reference, in the GKE world (hi! GKE SRE here), we use "masters" and "control plane" fairly interchangeably. For the individual components of the control plane, we just call them by their name (apiserver, controller manager, scheduler...), or collectively "control plane pods."

"Controller" would be nice as a shorter thing to say, but it's already heavily overloaded, and my personal experience at Google (where overloading terms is basically a sport at this point), if a term is too overloaded, people don't use it, or qualify it to the point where it's as/more verbose as "control plane."

Tongue in cheek: take a page from Starcraft, and call it the Overmind. A hive intelligence is not too stretched an analogy for k8s.

And following along that theme of hive minds, taking a page from the Borg: the Kubernetes Queen :)

@erriapo

This comment has been minimized.

Copy link

erriapo commented Feb 2, 2018

May I suggest using "Supervisor components". IMHO Supervisor is a great stand-in for Master.

@markyjackson-taulia

This comment has been minimized.

Copy link
Contributor

markyjackson-taulia commented Feb 2, 2018

I applaud this so very much!!!

@markyjackson-taulia

This comment has been minimized.

Copy link
Contributor

markyjackson-taulia commented Feb 2, 2018

I vote cluster control plane

@bgrant0607

This comment has been minimized.

Copy link
Member

bgrant0607 commented Feb 2, 2018

A couple quick comments (sorry):

  1. Controller already has a use in the system. Reusing would be very confusing.
  2. While I sympathize with the desire for conciseness, Supervisor is equally imprecise as master.
@swade1987

This comment has been minimized.

Copy link

swade1987 commented Feb 2, 2018

I think Control Plane makes sense to me.

@roldancer

This comment has been minimized.

Copy link

roldancer commented Feb 2, 2018

"Control Plane" is a widely adopted term ...

@codesnk

This comment has been minimized.

Copy link

codesnk commented Feb 3, 2018

Control plane is a term used in Software Defined Networking with "Controller" name used for module/s that manage the data plane. In the NFV domain, "Orchestrator" is the name used for the kind of things the K8S master does. Considering that k8s already uses "controllers", adopting the terms of control plane and even orchestrator will align it with the terminologies used elsewhere.

@mark-chilvers

This comment has been minimized.

Copy link

mark-chilvers commented Feb 3, 2018

"wheelhouse components"

@dzolnierz

This comment has been minimized.

Copy link

dzolnierz commented Feb 3, 2018

You should rename a "master" branch as well.

@davidopp

This comment has been minimized.

Copy link
Member

davidopp commented Feb 5, 2018

IME people use "control plane" to refer to some components that are not generally considered part of the "master" e.g. kubelet and kube-proxy. So I don't think it's a good substitute for "master."

@tizbac

This comment has been minimized.

Copy link

tizbac commented Feb 5, 2018

Seriously as with other instances of that problem, for me it looks completely retarded and ridicolous
Whoever is offended by terms that have been used in IT for over 30 years, has to rethink it, master and slave are the correct term if one part of the software or hardware is completely controlled by another part of the software or hardware.

@swade1987

This comment has been minimized.

Copy link

swade1987 commented Feb 5, 2018

@tizbac can I advise you don't use words like "retarded" in a public forum.

@Flukas88

This comment has been minimized.

Copy link

Flukas88 commented Feb 5, 2018

I'd use "ill advised" then

@MonsieurCellophane

This comment has been minimized.

Copy link

MonsieurCellophane commented Feb 5, 2018

Really. This richly deserves a "not a technical requirement/NOTABUG/WONTFIX" I cant envision a single man/hour wasted on this useless drivel.

@esolitos

This comment has been minimized.

Copy link

esolitos commented Feb 5, 2018

No please, not again.
Please don't waste the time fo N+1 people into a non real issue.
I'd really really go an poll the majority of people working in CS/IT asking if ANYONE has EVER felt discriminated by the naming master/slave. My speculation is that the % of "offended" people would be less than 1%.

This term is NOT related whatsoever from the "master race" concept or the "slave trade", as pointed out by others the master/slave nomenclature has been used in IT for decades to indicate that a specific part of a system id dependant on another part, if you see in any way a connection on the white masters and $skin-color slaves, I have a bad news for you: you are the racist, because you imply that this master/slave concept applies to humans. The fact that someone believed it in the past, doesn't make it real, and it's not changing the present that you erase the mistakes of the past.

Calling *ware components master/slave has never made anyone racist. Ever.

Sorry for this small rant, but I've seen far to many projects wasting time on this non issue in the past, creating long/eternal threads just to settle a damn nomenclature issue which no one was offended in the first place.

PS: The fact that this issue is raised and discussed purely by white caucasian men should make you think a little...

@taifu

This comment has been minimized.

Copy link

taifu commented Feb 5, 2018

I can't believe this. Really. I can't. This is ridiculous

@teknoraver

This comment has been minimized.

Copy link

teknoraver commented Feb 5, 2018

Am I the only one finding this ridiculous?

@brendandburns

This comment has been minimized.

Copy link
Contributor

brendandburns commented Feb 5, 2018

@taifu

This comment has been minimized.

Copy link

taifu commented Feb 5, 2018

Is it possible to express contrariety seeing so much time and word wasted for such a worthless problem? Master and server are two technical words and nobody, really, nobody with a grain of salt could seriously regard this as a real problem

@bgrant0607

This comment has been minimized.

Copy link
Member

bgrant0607 commented Feb 5, 2018

This conversation is no longer constructive and respectful. I am closing this issue.

We have already started to move towards more specific terms for technical reasons. That terminology will be discussed further in SIG Architecture.

@bgrant0607 bgrant0607 closed this Feb 5, 2018

@kubernetes kubernetes locked as too heated and limited conversation to collaborators Feb 5, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.