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

Replace use of term "Minion" #1111

Closed
jbeda opened this Issue Aug 29, 2014 · 76 comments

Comments

Projects
None yet
@jbeda
Contributor

jbeda commented Aug 29, 2014

There has been quite a bit of confusion over our use of the term "minion". While it captures what a worker node in a k8s cluster is well, it is highly associated with Salt. This has led to some confusion where people think that Salt is playing a larger role in k8s than it actually is.

I propose that we change from Minion to something that is more Kubernetes specific.

Questions:

  • Is this worthwhile? Should we do this?
  • What will this impact? I know that minion has made it into our API so that is something we'll have to address.
  • What term should we use to replace "Minion". Personally, I'd like to avoid any term that around "slave". Suggestions:
    • KNode
    • Koupi (greek for oar)
    • Rower
    • Krew
    • ???

@jbeda jbeda added the question label Aug 29, 2014

@roberthbailey

This comment has been minimized.

Member

roberthbailey commented Aug 29, 2014

A few other options:

  • A "Stevedore" is a man who loads ships (http://en.wikipedia.org/wiki/Stevedore)
  • Hyperetes is greek for "under-rower" and refers to the deck and command crew headed by the helmsman (kubernetes)
@lavalamp

This comment has been minimized.

Member

lavalamp commented Aug 29, 2014

I don't want to change, but if we do I would vote for something bland like "node".

@vmarmol

This comment has been minimized.

Contributor

vmarmol commented Aug 29, 2014

The name we use in code is kubelet. Any reason why we shouldn't consider that one? (idk if it falls under the "slave" umbrella)

@lavalamp

This comment has been minimized.

Member

lavalamp commented Aug 29, 2014

Kubelet is the name of the agent. "Minion" is what we call the machine the agent runs on.

@jbeda

This comment has been minimized.

Contributor

jbeda commented Aug 29, 2014

I kind of like stevedore but it is long. Hyperetes apparently has some connotations around 'slave' according to wikipedia. I also worry that it is hard to pronounce. We already get enough crap around the name "kubernetes".

What do you think about KNode? It is generic (as @lavalamp) wants but also kubernetes specific.

@dchen1107

This comment has been minimized.

Member

dchen1107 commented Aug 29, 2014

I vote for a change. Minion did cause confusion to me initially when I first worked on this project. But I don't have a better naming suggestion here, and ok with KNode for sure.

@proppy

This comment has been minimized.

Contributor

proppy commented Aug 29, 2014

"(k)node" or "machine" sounds good.

@roberthbailey

This comment has been minimized.

Member

roberthbailey commented Aug 29, 2014

We often shorten Kubernetes Master to KMaster, so I can see the argument for shortening Kubernetes Node to KNode. Personally I'd prefer to just spell it out and say Kubernetes Node since just "None" seems a bit too generic.

@thockin

This comment has been minimized.

Member

thockin commented Aug 29, 2014

Knode - pronounced "node". The K is silent. :P

On Fri, Aug 29, 2014 at 1:41 PM, roberthbailey notifications@github.com
wrote:

We often shorten Kubernetes Master to KMaster, so I can see the argument
for shortening Kubernetes Node to KNode. Personally I'd prefer to just
spell it out and say Kubernetes Node since just "None" seems a bit too
generic.

Reply to this email directly or view it on GitHub
#1111 (comment)
.

@lavalamp

This comment has been minimized.

Member

lavalamp commented Aug 29, 2014

I actually don't see a need, long-term, for distinguishing master vs. minion, since master components will be replicated & distributed across whatever minions are in the correct security zone to run them.

I still like short generic terms. "kbox" is better than knode, but I like "box" better. :) Or "unit", which takes a k in front even easier: kunit.

@thockin

This comment has been minimized.

Member

thockin commented Aug 29, 2014

Please no box or unit. box has pohysical implications, and unit is a
horrible name. Also systemd uses "unit".

On Fri, Aug 29, 2014 at 1:50 PM, Daniel Smith notifications@github.com
wrote:

I actually don't see a need, long-term, for distinguishing master vs.
minion, since master components will be replicated & distributed across
whatever minions are in the correct security zone to run them.

I still like short generic terms. "kbox" is better than knode, but I like
"box" better. :) Or "unit", which takes a k in front even easier: kunit.

Reply to this email directly or view it on GitHub
#1111 (comment)
.

@smarterclayton

This comment has been minimized.

Contributor

smarterclayton commented Aug 29, 2014

Having to make up a new word to describe a fairly standard concept (a slave, minion, node, host, box) seems risky. I'd prefer not to make up new terminology for people to learn when they administer new systems. Master is pretty unambiguous, let's pick a word that matches the common use for the things masters control.

@thockin

This comment has been minimized.

Member

thockin commented Aug 29, 2014

I really think knode is self-explanatory

On Fri, Aug 29, 2014 at 2:26 PM, Clayton Coleman notifications@github.com
wrote:

Having to make up a new word to describe a fairly standard concept (a
slave, minion, node, host, box) seems risky. I'd prefer not to make up new
terminology for people to learn when they administer new systems. Master is
pretty unambiguous, let's pick a word that matches the common use for the
things masters control.

Reply to this email directly or view it on GitHub
#1111 (comment)
.

@smarterclayton

This comment has been minimized.

Contributor

smarterclayton commented Aug 29, 2014

I'm a fan of node / knode / Kubernetes node.

@bgrant0607

This comment has been minimized.

Member

bgrant0607 commented Aug 29, 2014

I'm fine with node, but it's not very consistent with "master", which is also a node/host rather than a component in k8s. How about worker?

@jbeda

This comment has been minimized.

Contributor

jbeda commented Aug 29, 2014

Personally, worker sounds like a process running on one of the pool nodes.

If we use KNode, I think it is reasonable that users will figure out that the master host isn't necessarily running on one of the KNodes. A KNode is a node that is part of a k8s cluster.

@johnwilkes

This comment has been minimized.

Contributor

johnwilkes commented Aug 29, 2014

+1 for kNode: it's mercifully short, and not confusing. kMachine would also be fine.

(Although I like "minion" for being nicely tongue-in-cheek, it's a bit too easily confused with the functionality of a kubelet. But if you want to go down that path, then "vassal" would be nice - historically, some were immensely powerful. I agree that "worker" is confusing.)

A "master" is a software function, like a kubelet, not a (k)node, so I'm not sure it matters where it runs.

@erictune

This comment has been minimized.

Member

erictune commented Aug 30, 2014

I'm not sure why we need a distinctive/cute name for the machines that run kubelets.

In all of the documentation and code that K8s devs write, we will almost always be talking about machines that are part of a k8s cluster, and rarely about ones that are not. So "machine" will be clear enough.

For the ops folks who run k8s clusters alongside a range of other services, they will already have terms to distinguish machines with different roles, and don't need us to make one up.

I vote for "machine".

@lavalamp

This comment has been minimized.

Member

lavalamp commented Aug 30, 2014

"machine" is generic enough for me. I feel like we completely used up our cuteness quota with "Kubernetes".

@smarterclayton

This comment has been minimized.

Contributor

smarterclayton commented Sep 3, 2014

Summarizing:

The thing that tells other things what to do:

  • master
    • You can run the Kubernetes master inside a container on a host, or as a standalone service on a regular system.
  • ???

The thing that hosts pods

  • machine (a Kubernetes machine)
    • Pods are scheduled onto machines. Each machine runs an agent called the Kubelet that watches for changes in the list of pods.
  • node (a Kubernetes node)
    • Pods are scheduled onto nodes. Each node runs an agent called the Kubelet that watches for changes in the list of pods.
@roberthbailey

This comment has been minimized.

Member

roberthbailey commented Sep 3, 2014

+1 for node over machine.

@jbeda

This comment has been minimized.

Contributor

jbeda commented Sep 3, 2014

Here is what I'd say we go with:

  • Master: a set of services that need to run to control a cluster. Often this will run on a dedicated machine but it isn't required. Over time we'll look to have master components run across a cluster.
  • Kubernetes Node or KNode: a worker node that participates in a Kubernetes cluster. Replaces the use of minion now.
  • Kubelet The agent that communicates with master components to run and manage containers (in concert with Docker). Running a Kubelet is one of the primary things that defines a KNode.

I'm not a huge fan of plain "node" as it is pretty generic. KNode is short and kubernetes specific.

@smarterclayton

This comment has been minimized.

Contributor

smarterclayton commented Sep 3, 2014

So here's my counter to "K*" anything (I'm fine with Kubernetes *) - why not "KPods" or "KServices" or "KReplicationControllers"? Mesos doesn't call its slaves "MSlaves" (it's just a Mesos slave), and the same argument probably applies to most systems. It also avoids us having to do terrible things with casing in function definitions (or at least I think they're terrible):

func AddKNode(kNodeName string) {
}
@smarterclayton

This comment has been minimized.

Contributor

smarterclayton commented Sep 3, 2014

I think the K* / Kubernetes is either implied by context and thus unnecessary, or K by itself isn't sufficient to know what it is (if I told a random admin "check out this KNode" he'd look at me like I was crazy).

@jbeda

This comment has been minimized.

Contributor

jbeda commented Sep 3, 2014

Okay -- how about we say the official name is "Kubernetes Node" but that can be abbreviated KNode or Node as necessary. In code and such, plain old Node is perfectly okay if Kubernetes is implied.

As for K* -- Pods and ReplicationControllers are unique enough they don't need a K. Services is way too generic already and I'm sure we'll bikeshed on that soon :)

Someone want to sign up on doing this? Or did I sign myself up?

@jbeda

This comment has been minimized.

Contributor

jbeda commented Sep 3, 2014

(I was just reading this article on zookeeper where they talk about zNodes. Heh. https://www.found.no/foundation/ZooKeeper-King-of-Coordination/)

@erictune

This comment has been minimized.

Member

erictune commented Sep 5, 2014

Suggestion:

Rather than bikeshedding on each new naming decision, we should bikeshed once on picking a benevolent Name Czar, and then defer to the Czar, after a short discussion period, to make a decision on all Naming issues. That will result in faster progress and more thoughtful, consistent naming throughout the project.

@jbeda

This comment has been minimized.

Contributor

jbeda commented Sep 5, 2014

Why don't we hoist the bikesheding on bikesheding discussion to kubernetes-dev@googlegroups.com?

I'm going to call this one -- we'll rename minion to node. If the Kubernetes context is confusing, refer to them as Kubernetes Nodes or KNodes.

duglin added a commit to duglin/kubernetes that referenced this issue Sep 23, 2016

Change minion to node
Contination of kubernetes#1111

I tried to keep this PR down to just a simple search-n-replace to keep
things simple.  I may have gone too far in some spots but its easy to
roll those back if needed.

I avoided renaming `contrib/mesos/pkg/minion` because there's already
a `contrib/mesos/pkg/node` dir and fixing that will require a bit of work
due to a circular import chain that pops up. So I'm saving that for a
follow-on PR.

I rolled back some of this from a previous commit because it just got
to big/messy. Will follow up with additional PRs

Signed-off-by: Doug Davis <dug@us.ibm.com>

duglin added a commit to duglin/kubernetes that referenced this issue Sep 28, 2016

Change minion to node
Contination of kubernetes#1111

I tried to keep this PR down to just a simple search-n-replace to keep
things simple.  I may have gone too far in some spots but its easy to
roll those back if needed.

I avoided renaming `contrib/mesos/pkg/minion` because there's already
a `contrib/mesos/pkg/node` dir and fixing that will require a bit of work
due to a circular import chain that pops up. So I'm saving that for a
follow-on PR.

I rolled back some of this from a previous commit because it just got
to big/messy. Will follow up with additional PRs

Signed-off-by: Doug Davis <dug@us.ibm.com>

duglin added a commit to duglin/kubernetes that referenced this issue Sep 28, 2016

Change minion to node
Contination of kubernetes#1111

I tried to keep this PR down to just a simple search-n-replace to keep
things simple.  I may have gone too far in some spots but its easy to
roll those back if needed.

I avoided renaming `contrib/mesos/pkg/minion` because there's already
a `contrib/mesos/pkg/node` dir and fixing that will require a bit of work
due to a circular import chain that pops up. So I'm saving that for a
follow-on PR.

I rolled back some of this from a previous commit because it just got
to big/messy. Will follow up with additional PRs

Signed-off-by: Doug Davis <dug@us.ibm.com>

duglin added a commit to duglin/kubernetes that referenced this issue Sep 28, 2016

Change minion to node
Contination of kubernetes#1111

I tried to keep this PR down to just a simple search-n-replace to keep
things simple.  I may have gone too far in some spots but its easy to
roll those back if needed.

I avoided renaming `contrib/mesos/pkg/minion` because there's already
a `contrib/mesos/pkg/node` dir and fixing that will require a bit of work
due to a circular import chain that pops up. So I'm saving that for a
follow-on PR.

I rolled back some of this from a previous commit because it just got
to big/messy. Will follow up with additional PRs

Signed-off-by: Doug Davis <dug@us.ibm.com>

duglin added a commit to duglin/kubernetes that referenced this issue Sep 28, 2016

Change minion to node
Contination of kubernetes#1111

I tried to keep this PR down to just a simple search-n-replace to keep
things simple.  I may have gone too far in some spots but its easy to
roll those back if needed.

I avoided renaming `contrib/mesos/pkg/minion` because there's already
a `contrib/mesos/pkg/node` dir and fixing that will require a bit of work
due to a circular import chain that pops up. So I'm saving that for a
follow-on PR.

I rolled back some of this from a previous commit because it just got
to big/messy. Will follow up with additional PRs

Signed-off-by: Doug Davis <dug@us.ibm.com>

k8s-merge-robot added a commit that referenced this issue Sep 29, 2016

Merge pull request #25260 from duglin/minion
Automatic merge from submit-queue

Change minion to node

Continuation of #1111

I tried to keep this PR down to just a simple search-n-replace to keep
things simple.  I may have gone too far in some spots but its easy to
roll those back if needed - just let me know.

I avoided renaming `contrib/mesos/pkg/minion` because there's already
a `contrib/mesos/pkg/node` dir and fixing that will require a bit of work
due to a circular import chain that pops up. So I'm saving that for a
follow-on PR.

Signed-off-by: Doug Davis <dug@us.ibm.com>

k8s-merge-robot added a commit that referenced this issue Dec 14, 2016

Merge pull request #37272 from brendandburns/cleanup
Automatic merge from submit-queue

Remove 'minion' from the code in two places in favor of 'node'

Part of #1111

xingzhou pushed a commit to xingzhou/kubernetes that referenced this issue Dec 15, 2016

Change minion to node
Contination of kubernetes#1111

I tried to keep this PR down to just a simple search-n-replace to keep
things simple.  I may have gone too far in some spots but its easy to
roll those back if needed.

I avoided renaming `contrib/mesos/pkg/minion` because there's already
a `contrib/mesos/pkg/node` dir and fixing that will require a bit of work
due to a circular import chain that pops up. So I'm saving that for a
follow-on PR.

I rolled back some of this from a previous commit because it just got
to big/messy. Will follow up with additional PRs

Signed-off-by: Doug Davis <dug@us.ibm.com>

xingzhou pushed a commit to xingzhou/kubernetes that referenced this issue Dec 15, 2016

Change minion to node
Contination of kubernetes#1111

I tried to keep this PR down to just a simple search-n-replace to keep
things simple.  I may have gone too far in some spots but its easy to
roll those back if needed.

I avoided renaming `contrib/mesos/pkg/minion` because there's already
a `contrib/mesos/pkg/node` dir and fixing that will require a bit of work
due to a circular import chain that pops up. So I'm saving that for a
follow-on PR.

I rolled back some of this from a previous commit because it just got
to big/messy. Will follow up with additional PRs

Signed-off-by: Doug Davis <dug@us.ibm.com>

xingzhou pushed a commit to xingzhou/kubernetes that referenced this issue Dec 15, 2016

Merge pull request kubernetes#25260 from duglin/minion
Automatic merge from submit-queue

Change minion to node

Continuation of kubernetes#1111

I tried to keep this PR down to just a simple search-n-replace to keep
things simple.  I may have gone too far in some spots but its easy to
roll those back if needed - just let me know.

I avoided renaming `contrib/mesos/pkg/minion` because there's already
a `contrib/mesos/pkg/node` dir and fixing that will require a bit of work
due to a circular import chain that pops up. So I'm saving that for a
follow-on PR.

Signed-off-by: Doug Davis <dug@us.ibm.com>
@bgrant0607

This comment has been minimized.

Member

bgrant0607 commented Mar 7, 2017

Minion is still present in scripts in /cluster, such as:

NODE_TAG="${INSTANCE_PREFIX}-minion"

We should at least be able to eradicate it when we fully remove provider-specific code from this repo.

@andrey01

This comment has been minimized.

andrey01 commented Jun 16, 2017

Not sure if this is the right place and time, but how about having the master and a worker types of the node? (where node is a single system in a cluster of many systems)

I think that would remove one level of ambiguity.

@macalinao

This comment has been minimized.

macalinao commented Jun 19, 2017

Sad! I love minions.
screen shot 2017-06-19 at 4 17 50 pm

@fejta-bot

This comment has been minimized.

fejta-bot commented Dec 28, 2017

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

@ghost

This comment has been minimized.

ghost commented Dec 28, 2017

@bgrant0607

This comment has been minimized.

Member

bgrant0607 commented Jan 23, 2018

https://github.com/kubernetes/kubernetes/search?utf8=%E2%9C%93&q=minion&type=

This only exists in a few places in the cluster directory, which we're going to eliminate at some point, so this done enough

@bgrant0607 bgrant0607 closed this Jan 23, 2018

dmoneil2 pushed a commit to intel/multus-cni that referenced this issue Feb 28, 2018

Dave
Remove referecne to minions
The term "minion" was changed to "node" in 2014,  The discussion and eventual deprcation is documented on 
kubernetes/kubernetes#1111

"A node is a worker machine in Kubernetes, previously known as a minion." - https://kubernetes.io/docs/concepts/architecture/nodes/

updating the documentation to reflect correct terminology

wenlxie pushed a commit to wenlxie/kubernetes that referenced this issue May 30, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment