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
1 of 2 tasks
jbpivotal opened this issue Dec 1, 2017 · 40 comments
Closed
1 of 2 tasks

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

jbpivotal opened this issue Dec 1, 2017 · 40 comments
Labels
committee/steering Denotes an issue or PR intended to be handled by the steering committee. kind/bug Categorizes issue or PR as related to a bug. sig/architecture Categorizes an issue or PR as relevant to SIG Architecture. wg/naming Categorizes an issue or PR as relevant to WG Naming.
Projects

Comments

@jbpivotal
Copy link

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
Copy link
Contributor

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

/cc @sarahnovotny, @parispittman

@parispittman
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
Copy link
Contributor

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
Copy link
Author

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

@idvoretskyi
Copy link
Member

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

@idvoretskyi
Copy link
Member

cc @kubernetes/sig-architecture-bugs

@k8s-ci-robot k8s-ci-robot added sig/architecture Categorizes an issue or PR as relevant to SIG Architecture. kind/bug Categorizes issue or PR as related to a bug. labels Jan 31, 2018
@bgrant0607
Copy link
Member

I usually use "control plane".

Minion->node rename:
kubernetes/kubernetes#1111

@bgrant0607 bgrant0607 added the committee/steering Denotes an issue or PR intended to be handled by the steering committee. label Jan 31, 2018
@bgrant0607
Copy link
Member

cc @kubernetes/steering-committee

@jbeda
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
Copy link
Member

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
Copy link
Contributor

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

@smarterclayton
Copy link
Contributor

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
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
Copy link
Member

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
Copy link
Member

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

  • cluster control plane
  • nucleus apiserver
  • dedicated infrastructure nodes

@jfoy
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
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
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
Copy link

erriapo commented Feb 2, 2018

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

@markjacksonfishing
Copy link
Contributor

I applaud this so very much!!!

@markjacksonfishing
Copy link
Contributor

I vote cluster control plane

@bgrant0607
Copy link
Member

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
Copy link

I think Control Plane makes sense to me.

@roldancer
Copy link

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

@codesnk
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
Copy link

"wheelhouse components"

@dzolnierz
Copy link

You should rename a "master" branch as well.

@davidopp
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
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
Copy link

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

@Flukas88
Copy link

Flukas88 commented Feb 5, 2018

I'd use "ill advised" then

@MonsieurCellophane
Copy link

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

@esolitos
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
Copy link

taifu commented Feb 5, 2018

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

@teknoraver
Copy link

Am I the only one finding this ridiculous?

@brendandburns
Copy link
Contributor

brendandburns commented Feb 5, 2018 via email

@taifu
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
Copy link
Member

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.

@kubernetes kubernetes locked as too heated and limited conversation to collaborators Feb 5, 2018
@sftim
Copy link
Contributor

sftim commented Aug 13, 2020

/wg naming

@k8s-ci-robot k8s-ci-robot added the wg/naming Categorizes an issue or PR as relevant to WG Naming. label Aug 13, 2020
@justaugustus justaugustus added this to Done in WG Naming Sep 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
committee/steering Denotes an issue or PR intended to be handled by the steering committee. kind/bug Categorizes issue or PR as related to a bug. sig/architecture Categorizes an issue or PR as relevant to SIG Architecture. wg/naming Categorizes an issue or PR as relevant to WG Naming.
Projects
WG Naming
  
Done
Development

No branches or pull requests