✨ Master -> Control Plane

[vincepri]

Renames master to controlplane as discussed in the Jan 31st steering meeting

Related: kubernetes/website#6525

[vincepri]

Related to kubernetes-sigs/cluster-api#688

[DirectXMan12]

1. Can you actually track down where the decision was made, to avoid any future drama? The meeting docs seemed to imply "we punted on this decision", and the thread was closed as too contentious. Since this issue tends to cause "commotion" (to put it lightly), having concrete documentation of a decision could be useful to avoid drama in the future.

2. If we're going to rename, we should be accurate and thorough in doing so. Half of your renames ("API server --> control plane") have made the comments less accurate. This is an API server URL (as the comments imply), and we should reference it as such.

Here's what I propose:

1. Find a link to the actual decision.
2. Rename variables accurately (API server)
3. Add a comment that the flag is still called master for legacy reasons
4. Mark the flag as deprecated (it's a silly flag anyway -- it's mostly redundant with --kubeconfig)
5. (possibly) figure out a new flag to use across kube if we think the flag's functionality isn't silly

[DirectXMan12]

Also, please add a change type indicator to the PR title (see the PR template and README.md for more details).

(P.S. No need to use Signed-of-by here -- it's meaningless since we use a CLA, and just adds visual noise to the commit message)

[vincepri]

Thanks for the feedback @DirectXMan12. I’ll try to hunt down the decision, I came here from the cluster api issue referenced. If I can’t find enough information I am ok to close this. I should probably have done more research around the decision beforehand, I didn’t expect it to cause trouble, apologies!

[vincepri]

/cc @neolit123

[coderanger]

👍 for --api-server and similar as being both more accurate and nicer :)

[neolit123]

@DirectXMan12

Can you actually track down where the decision was made, to avoid any future drama? The meeting docs seemed to imply "we punted on this decision", and the thread was closed as too contentious. Since this issue tends to cause "commotion" (to put it lightly), having concrete documentation of a decision could be useful to avoid drama in the future.

i'd argue that there is no drama, but rather this has been a soft transition for the project.
kubeadm has already phased away from "master" in both code base and docs (mostly) over the course of an year.

community meeting announcement by Joe Beda is from Feb 1st 2018:
https://github.com/kubernetes/community/blob/master/communication/meeting-notes-archive/q1-2_2018_community_meeting_minutes.md#february-1-2018---recording

VOD timestamp:
https://youtu.be/Oj-0l7vdUac?t=2974

If we're going to rename, we should be accurate and thorough in doing so. Half of your renames ("API server --> control plane") have made the comments less accurate. This is an API server URL (as the comments imply), and we should reference it as such.

this flag, if not redundant, seems like it should be the API Server URL, indeed.
but i'm mostly leaning towards redundant.

as outlined in the above announcement, "control plane" encapsulates a composite meaning. if we are targeting an individual component, we should do so in docs and flags for clarity.

[DirectXMan12]

I should probably have done more research around the decision beforehand, I didn’t expect it to cause trouble, apologies!

No worries :-) Sorry if my message above came off a bit harsh.

i'd argue that there is no drama, but rather this has been a soft transition for the project.
kubeadm has already phased away from "master" in both code base and docs (mostly) over the course of an year.

Yeah, it's been pretty smooth, AFAICT, after that initial thread. Wanted the reference to point to just in case (that thread linked got a bit nasty, and having a "this has already been decided here, this is not the place to discuss" button is nice to have around).

community meeting announcement by Joe Beda is from Feb 1st 2018:
https://github.com/kubernetes/community/blob/master/communication/meeting-notes-archive/q1-2_2018_community_meeting_minutes.md#february-1-2018---recording

Perfect, thanks!

but i'm mostly leaning towards redundant.

Yeah, I'm leaning towards just marking as deprecated (so as not to break people, but it'll hide it in help, etc).

as outlined in the above announcement, "control plane" encapsulates a composite meaning. if we are targeting an individual component, we should do so in docs and flags for clarity.

👍 (more or less what I was saying above, I think)

[vincepri]

@DirectXMan12 @neolit123 Updated the PR with the latest comment, the flag is marked as deprecated both in code and description suggesting users to switch to --kubeconfig

[neolit123]

switch to apiServerAddress as the variable name for the deprecation period?

[vincepri]

I'm fine either way, @DirectXMan12 ?

[DirectXMan12]

yeah, use apiServerURL as the variable name sot that we're clear.

[vincepri]

Is CI broken? I tested locally on master and it also shows the same failures.

[DirectXMan12]

Is CI broken

I think it was fixed in a recent PR. Rebase on master and it should be fixed.

[vincepri]

Rebased and updated the PR with the variable name change as suggested above.

[DirectXMan12]

/lgtm
/approve

(changed to :sparkles: since it's no longer a break change, just a deprecation)

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: DirectXMan12, vincepri

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [DirectXMan12]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment