Change:
There are a number of variable and functions that can outright be renamed to refer to "control plane" instead of "master". There are also some flags which should be deprecated (and corresponding changes made in jobs) /kind cleanup /wg naming /sig testing /area test
can we get some test from itthis issue is contained of too many test ?
/cc
/cc
/good-first-issue
These files have been modified.
I have PR for the changes, I have some questions, about the changes. With current attached PR I have not changed in command line parameters, I guess we need to retire them and provide new ones. is that right? I would like create a different PR reieiw for those changes. Another question, you also talked about changing jobs? Can you please explain more which jobs need to be changed? Are those need to be updated after change in cmd line params only? Where can I references to them? Thanks.
/reopen Please don't "Fixes:" this issue via PR's
Reopened this issue. <detailsIn response to : /reopen Please don't "Fixes:" this issue via PR's Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted /remove-good-first-issue We are lacking a guide to ensure we consistently rename things, and I'm seeing a lot of blind s/master/instance which I believe is inappropriate
/cc
Really nice to have guideline to explain how to fix this issue. I am checking whole PRs for this issue and those points with priority order are Replace with actual component name like , , , etc. if possible Even if is not after , we need to replace the with Replace with Replace with I still have questions like How to capitalize in comments? (Control plane? control plane? Control Plane?)
/cc
this seems like a question for this search query at reveals that the capitalization varies: i would recommend :control plane", because it is not the name of an object, it is the object. an example of that is the following - if one is talking about a k8s node topology wise, then "node" does not have to be capitalized. yet if one is talking about the API object named "Node", then we should capitalize it. maybe we should clarify "control plane" here too.
yes, but only if this is not a case of: i think saw a few cases of that.
Thanks for your comment! Even if node is not after master, we need to replace the master with control plane node Yes, I agree with you here. I think these rules should be applied with the order.
thank you for enumerating my concerns, I think I want to explain the reasoning a bit more though: Master is used interchangeably to refer to different concepts. Our goal here is not just to use more inclusive language, but to be more specific about what we're referring to. This includes maintaining the appropriate level of abstraction; sometimes we want to talk about the group as a whole, sometimes we want to talk about a specific instance or member of the group. "The thing that hosts all components responsible for controlling my kubernetes cluster" -control plane "The thing I talk to in order to interact with my kubernetes cluster" -control plane, endpoint "A specific kube-apiserver instance that is part of the kubernetes control plane" -apiserver, instance (this is what I understand to be) "A node that hosts components that are part of the control plane" -control plane node "A node that is unschedulable" -unschedulable node "A specific component that is part of the control plane" -apiserver, controller-manager, scheduler, etcd When using terminology that could be seen as generic, ask yourself, is there enough context available to disambiguate potential meanings for the reader? e.g. "instance" - an instance of what? "apiserver" - is this a generic apiserver? is this a kubernetes apiserver? is this part of the kubernetes control plane? "endpoint" - what's at the other end of this endpoint? I completely agree with comments on capitalization. I would almost always go with "control plane" in docs or comments. so having said all that, I think your recommendations are solid, except Even if node is not after master, we need to replace the master with control plane node This is really going to depend on which of the above concepts "master" is referring to.
Thank you for your guideline! That is very clear and I understand what we need to take care of during PR reviews. We are ready to go forward.
One other set of assumptions / definition I see come up (in tests, anyway): there is exactly one instance of each control plane component there is exactly one control plane node that hosts these components Basically these are assumptions that are tangled up with the e2e framework's concept of a "provider", usually assuming the kube- gce implementation with a set of default parameters. We should really be untangling this while we're renaming things, but I don't have a concrete proposal on the best path forward. Extract operations into the provider interface? Make a new kind of provider (control plane provider)? Look at cluster provider? At the very least we should probably ensure names refer to whether they're trying to mutate a single instance of a specific control plane component, all instances, or the control plane in its entirety,
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/priority important-longterm I will circle back on the PR's I blocked now that is merged
/remove-help Going to take off /help until I can provide clearer breakout/instructions
/milestone v1.21 Would like to see if we can drive this completion in v1.21 timeframe
Hello! This issue has not been updated for a long time, so I'd like to check what's the status. The code freeze is starting March 9th, 2021 (about 1 week from now). As the Issue is tagged for 1.21, is it still planned for this release?
/milestone clear Parts of this could qualify for test freeze but it is unlikely I am going to find time to push this forward
/help This currently has no assignee. Is someone interested in taking this up?
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help This currently has no assignee. Is someone interested in taking this up? Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Hi, I'm interesting in taking this task, however I'd like to ask if let's say we have something like this which actually refer to csi plugin, do we need to change it as well?
I can try to work on this if it's still available?
Made a PR that's ready for review ^
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
} }() <del> for _, masterAddress := range masterAddresses { e2enetwork.BlockNetwork(host, masterAddress) </del> <ins> for _, instanceAddress := range controlPlaneAddresses { e2enetwork.BlockNetwork(host, instanceAddress) </ins> } ginkgo.By("Expect to observe node and pod status change from Ready to NotReady after network partition")

}() go controller.Run(stopCh) <del> ginkgo.By(fmt.Sprintf("Block traffic from node %s to the master", node.Name)) </del> <ins> ginkgo.By(fmt.Sprintf("Block traffic from node %s to the control plane", node.Name)) </ins> host, err := e2enode.GetExternalIP(&node) framework.ExpectNoError(err) <del> masterAddresses := framework.GetAllMasterAddresses(c) </del> <ins> controlPlaneAddresses := framework.GetControlPlaneAddresses(c) </ins> defer func() { <del> ginkgo.By(fmt.Sprintf("Unblock traffic from node %s to the master", node.Name)) for _, masterAddress := range masterAddresses { e2enetwork.UnblockNetwork(host, masterAddress) </del> <ins> ginkgo.By(fmt.Sprintf("Unblock traffic from node %s to the control plane", node.Name)) for _, instanceAddress := range controlPlaneAddresses { e2enetwork.UnblockNetwork(host, instanceAddress) </ins> } if ginkgo.CurrentGinkgoTestDescription().Failed {

expectNodeReadiness(true, newNode) }() <del> for _, masterAddress := range masterAddresses { e2enetwork.BlockNetwork(host, masterAddress) </del> <ins> for _, instanceAddress := range controlPlaneAddresses { e2enetwork.BlockNetwork(host, instanceAddress) </ins> } ginkgo.By("Expect to observe node and pod status change from Ready to NotReady after network partition")

if err != nil { framework.Failf("Error getting node external ip : %v", err) } <del> masterAddresses := framework.GetAllMasterAddresses(c) ginkgo.By(fmt.Sprintf("block network traffic from node %s to the master", node.Name)) </del> <ins> controlPlaneAddresses := framework.GetControlPlaneAddresses(c) ginkgo.By(fmt.Sprintf("block network traffic from node %s to the control plane", node.Name)) </ins> defer func() { // This code will execute even if setting the iptables rule failed. // It is on purpose because we may have an error even if the new rule // had been inserted. (yes, we could look at the error code and ssh error // separately, but I prefer to stay on the safe side). <del> ginkgo.By(fmt.Sprintf("Unblock network traffic from node %s to the master", node.Name)) for _, masterAddress := range masterAddresses { UnblockNetwork(host, masterAddress) </del> <ins> ginkgo.By(fmt.Sprintf("Unblock network traffic from node %s to the control plane", node.Name)) for _, instanceAddress := range controlPlaneAddresses { UnblockNetwork(host, instanceAddress) </ins> } }()

if !e2enode.WaitConditionToBe(c, node.Name, v1.NodeReady, true, resizeNodeReadyTimeout) { framework.Failf("Node %s did not become ready within %v", node.Name, resizeNodeReadyTimeout) } <del> for _, masterAddress := range masterAddresses { BlockNetwork(host, masterAddress) </del> <ins> for _, instanceAddress := range controlPlaneAddresses { BlockNetwork(host, instanceAddress) </ins> } framework.Logf("Waiting %v for node %s to be not ready after simulated network failure", resizeNodeNotReadyTimeout, node.Name)

return externalIP, internalIP, hostname } <del> // GetAllMasterAddresses returns all IP addresses on which the kubelet can reach the master. </del> <ins> // GetControlPlaneAddresses returns all IP addresses on which the kubelet can reach the control plane. </ins> // It may return internal and external IPs, even if we expect for // e.g. internal IPs to be used (issue #56787), so that we can be <del> // sure to block the master fully during tests. func GetAllMasterAddresses(c clientset.Interface) []string { </del> <ins> // sure to block the control plane fully during tests. func GetControlPlaneAddresses(c clientset.Interface) []string { </ins> externalIP, internalIP, _ := getMasterAddresses(c) ips := sets.NewString()

framework.Failf("did not find any node addresses") } <del> masterAddresses := framework.GetAllMasterAddresses(cs) for _, masterAddress := range masterAddresses { assertNotReachableHTTPTimeout(masterAddress, ports.InsecureKubeControllerManagerPort, firewallTestTCPTimeout) assertNotReachableHTTPTimeout(masterAddress, kubeschedulerconfig.DefaultInsecureSchedulerPort, firewallTestTCPTimeout) </del> <ins> controlPlaneAddresses := framework.GetControlPlaneAddresses(cs) for _, instanceAddress := range controlPlaneAddresses { assertNotReachableHTTPTimeout(instanceAddress, ports.InsecureKubeControllerManagerPort, firewallTestTCPTimeout) assertNotReachableHTTPTimeout(instanceAddress, kubeschedulerconfig.DefaultInsecureSchedulerPort, firewallTestTCPTimeout) </ins> } assertNotReachableHTTPTimeout(nodeAddr, ports.KubeletPort, firewallTestTCPTimeout) assertNotReachableHTTPTimeout(nodeAddr, ports.KubeletReadOnlyPort, firewallTestTCPTimeout)