jiebi/CodeConvo huggingface dataset:
Change:
return p, err } <ins> // WaitForRCToStabilize waits till the RC has a matching generation/replica count between spec and status. func WaitForRCToStabilize(c *client.Client, ns, name string, timeout time.Duration) error { options := api.ListOptions{FieldSelector: fields.Set{ "metadata.name":      name, "metadata.namespace": ns, }.AsSelector()} w, err := c.ReplicationControllers(ns).Watch(options) if err != nil { return err } _, err = watch.Until(timeout, w, func(event watch.Event) (bool, error) { switch event.Type { case watch.Deleted: return false, apierrs.NewNotFound(unversioned.GroupResource{Resource: "replicationcontrollers"}, "") } switch rc := event.Object.(type) { case *api.ReplicationController: if rc.Name == name && rc.Namespace == ns && rc.Generation <= rc.Status.ObservedGeneration && rc.Spec.Replicas == rc.Status.Replicas { return true, nil } Logf("Waiting for rc %s to stabilize, generation %v observed generation %v spec.replicas %d status.replicas %d", name, rc.Generation, rc.Status.ObservedGeneration, rc.Spec.Replicas, rc.Status.Replicas) } return false, nil }) return err } </ins> func WaitForPodToDisappear(c *client.Client, ns, podName string, label labels.Selector, interval, timeout time.Duration) error { return wait.PollImmediate(interval, timeout, func() (bool, error) { Logf("Waiting for pod %s to disappear", podName)

Discussion:
The desired behavior is: Create spec.Replica pods As pods keep coming down watch, update status.Replicas, so users have pseudo real-time feedback If during this time someone submits a new update to spec.Replicas that bumps up the generation, dont update status.Generation to match Update Generation when pending creates/deletes are observed Without the third check, we could confuse a client who quicky scales up/down into thinking the current is for their spec (because spec will match status, but we still have pending creates/deletes). Observed in: Where we see: Because kubectl rolling-update deleted the rc soon after creation.
See discussion in Un-assigning myself since immediate issue of test flake is solved, and we need to think through how we're going to expose generation.
Issues go stale after 30d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Change:
nsKubeconfig.QPS *= 20 nsKubeconfig.Burst *= 100 namespaceKubeClient := clientset.NewForConfigOrDie(nsKubeconfig) <ins> return startModifiedNamespaceController(ctx, namespaceKubeClient, nsKubeconfig) } func startModifiedNamespaceController(ctx ControllerContext, namespaceKubeClient clientset.Interface, nsKubeconfig *restclient.Config) (http.Handler, bool, error) { </ins> dynamicClient, err := dynamic.NewForConfig(nsKubeconfig) if err != nil {

Discussion:
In we observed a crashlooping controller cause a cluster cold boot failure, as controller-manager wasn't able to stay up long enough to run the deployment that would have fixed the problem. We should audit everything that runs in kube-controller-manager and ensure that they all fail gracefully enough to prevent crashloops, or make them individually restart in that case, instead of the process. Longer term, we should consider classifying the controllers by run level or bootstrap order (), and splitting them into separate binaries or changing the start-up order in kcm to make sure this sort of thing doesn't happen in the future.
Same issue with metrics-server, using minikube. Also reproduced on our test cluster. Steps to reproduce: Set up localkube Install metrics-server Stop minikube: sudo minikube stop Start minikube: sudo -E minikube start --vm-driver=none Expected: Kubernetes is running Actual: Kubernetes is dead Logs: Workaround: To fix the system, we must delete the metrics-server: Now kubernetes will start normally. After that we can reinstall the metrics server, and it will be ok.
Related:
This will be a hard problem to fix permanently. In all likelihood, we should stop allowing Fatalf() in kubernetes/kubernetes, but as you can see we do this to ourselves right here...
/kind bug
I also think this bug would benefit from an e2e test where we misconfigure things in a variety of ways and verify that KCM still comes up and stays up: [ ] misconfigured apiservice [ ] broken service attached to that apiservice [ ] RBAC rules that disallow things. maybe everything! [ ] webhooks that disallow everything [ ] yr example here
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
Change:
### Step Zero: Prerequisites <del> This example assumes that you have a basic understanding of kubernetes services and that you have forked the repository and [turned up a Kubernetes cluster](https://github.com/GoogleCloudPlatform/kubernetes#contents): This example requires a kubernetes cluster. </del> <ins> This example requires a kubernetes cluster.  See the [Getting Started guides](../../docs/getting-started-guides) for how to get started. </ins> <del> See the companion [Setup Kubernetes](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/guestbook/SETUP.md) for some quick notes on how to get started. *If* you are running from source, replace commands such as "kubectl" below with calls to cluster/kubectl.sh. </del> <ins> If you are running from source, replace commands such as `kubectl` below with calls to `cluster/kubectl.sh`. </ins> ### Step One: Fire up the redis master

Discussion:
Working through the , I was confused about how to get setup with an initial binary and cluster. I think the section should point to the , rather than the document. relies on , which is being deprecated, and just points to the getting-started guides anyway.
LGTM.
Change:
<ins> /* Copyright 2021 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package validation import "testing" func TestMaskTrailingDash(t *testing.T) { testCases := []struct { beforeMasking        string expectedAfterMasking string description          string }{ { beforeMasking:        "", expectedAfterMasking: "", description:          "empty string", }, { beforeMasking:        "-", expectedAfterMasking: "-", description:          "only a single dash", }, { beforeMasking:        "-foo", expectedAfterMasking: "-foo", description:          "has leading dash", }, { beforeMasking:        "-foo-", expectedAfterMasking: "-foa", description:          "has both leading and trailing dashes", }, { beforeMasking:        "b-", expectedAfterMasking: "a", description:          "has trailing dash", }, { beforeMasking:        "ab", expectedAfterMasking: "ab", description:          "has neither leading nor trailing dashes", }, } for _, tc := range testCases { afterMasking := maskTrailingDash(tc.beforeMasking) if afterMasking != tc.expectedAfterMasking { t.Errorf("error in test case: %s. expected: %s, actual: %s", tc.description, tc.expectedAfterMasking, afterMasking) } } } </ins>

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --My controller had a bug where it was setting , and the client I was using () returned an internal server error when I tried to create it. In the API server logs, there was a panic at this line: apimachinery validation logic should handle this case gracefully, and the API server should return a helpful error to the client. Create a resource with the GenerateName field set to "-". This happened on Kind running locally & AKS, both v1.20.2 Kubernetes version (use ): v1.20.2 Cloud provider or hardware configuration: Kind/laptop, AKS OS (e.g: ): Darwin/LinuxKit (i.e. docker for macOS), AKS Install tools: Kind
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig apimachinery 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
/sig api-machinery
/assign
/assign /triage accepted
Change:
accBody: "ok body", }, { <ins> handler:    headerCounterHandler, reqHeaders: http.Header{}, health:     probe.Success, accBody:    "4", }, { handler:    headerKeysNamesHandler, reqHeaders: http.Header{}, health:     probe.Success, accBody:    "AcceptnAccept-EncodingnConnectionnUser-Agent", }, { </ins> handler: headerEchoHandler, reqHeaders: http.Header{ "X-Muffins-Or-Cupcakes": {"muffins"},

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : I would like that besides User-agent we the Accept header as well with the "acept all" default. Just like curl does. Why is this needed: Because it was my expectation that the probe would work similarly to a curl but is not the case. I think more folks can hit this situation and waste some time to finally sort it out If this is not something you would like to add I would then like the docs to mention this specifically. _ PS: I would love to propose the improvement my self
/sig node network
/assign
Is the goal simply to avoid tripping over servers that look for that header? I don't think this presents any hazards - is that right? If so, it seems like a simple PR if you want to tackle it. /triage accepted /kind feature
cool! will look into it! thanks :)
Hello sorry but be bugging you, but I have opened the PR but I had 0 response since then. I think I have met all the requirements, so I was wondering (as this is my first PR in k8s) if you could help me a bit. Thanks anyway.
Change:
if err != nil { return err } <del> if pod.Status.Phase != api.PodRunning { return fmt.Errorf("pod %s is not running and cannot be attached to; current phase is %s", p.PodName, pod.Status.Phase) </del> <ins> if pod.Status.Phase == api.PodSucceeded || pod.Status.Phase == api.PodFailed { return fmt.Errorf("cannot attach a container in a completed pod; current phase is %s", pod.Status.Phase) </ins> } p.Pod = pod // TODO: convert this to a clean "wait" behavior }

Discussion:
Related issue
is there a simple example that you used to recreate the problem?
I used exactly the example below: So Pod sflask-w-init gets into pending state "Init:0/1" forever. Then you can try to run and you can see that is not working while invoking corresponding command with docker works - it displays current date every second.
thanks for the detailed test, please see the PR :)
Duh! already has a PR
Change:
return fakeRuntime, endpoint } <del> func createRemoteRuntimeService(endpoint string, t *testing.T) internalapi.RuntimeService { runtimeService, err := remote.NewRemoteRuntimeService(endpoint, 15*time.Second, oteltrace.NewNoopTracerProvider()) </del> <ins> func createRemoteRuntimeService(endpoint string, t *testing.T, tp oteltrace.TracerProvider) internalapi.RuntimeService { runtimeService, err := remote.NewRemoteRuntimeService(endpoint, 15*time.Second, tp) </ins> require.NoError(t, err) return runtimeService }

Discussion:
spans are not being parented to other spans - propagation of context seems broken. More context: spans should be parented to other spans enable kubelet tracing at v1.28 and hook up a tracing backend. No response <detailsv1.28 at least </details<detailsNot sure this matters. </details<details</details<details</details<details</details<details</details
/sig instrumentation /assign
/triage accepted
!
repro steps:
/assign Thanks for helping to look into this! Feel free to post the findings here you shared with me on slack
GitHub didn't allow me to assign the following users: fatsheep9146. Note that only with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 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
Thanks! I will post this ASAP
The broken issue is due to the pr , which try to propagate context brought by pod worker to syncPod function in order to let the syncPod can be interrupted in time by other asynchronous routines, for example eviction. But in the line we did not pass the context which contain the parent span and trace into function, so the trace is broken. So I want to fix this by passing the into , which is also desired in comment But passing the ctx into syncPod may have something other to do as described in comments, so I tried to fix as comments advised.
cc
Change:
} func (s *CustomColumnsPrinter) PrintObj(obj runtime.Object, out io.Writer) error { <del> w := tabwriter.NewWriter(out, columnwidth, tabwidth, padding, padding_character, flags) </del> <ins> if w, found := out.(*tabwriter.Writer); !found { w = GetNewTabWriter(out) out = w defer w.Flush() } </ins> t := reflect.TypeOf(obj) if !s.NoHeaders && t != s.lastType {

Discussion:
Compare the following two outputs (note the bad alignment in the last line): The custom-columns string is exactly the same in both cases, but something messes up the column widths when using openapi print columns. Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Columns printed when using are misaligned. What you expected to happen: Columns in all rows should be aligned. How to reproduce it (as minimally and precisely as possible): Deploy Service Catalog, patched with Run the above two commands Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"9+", GitVersion:"v1.9.0-alpha.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-11-15T23:06:17Z", GoVersion:"go1.9.1", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-10-17T15:09:55Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} (same behavior with kubectl built from current master branch)
/sig api-machinery
/remove-sig api-machinery /sig cli PR is ready:
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
Change:
// kubelet.PortForwarder. type fakePortForwarder struct { lock sync.Mutex <ins> // stores data expected from the stream per port expected map[uint16]string </ins> // stores data received from the stream per port received map[uint16]string // data to be sent to the stream per port

Discussion:
I wanted to drop a note that I haven't forgotten about this issue. I have spent some time investigating and have yet to determine why some test runs result in the data not being forwarded correctly. I hope to resume digging into this soon, but I've got some planning tasks I need to complete first.
I have determined the root cause of this. In the test case, it: a port forwarding session, listening on a local port a TCP connection to the local port a goroutine copies data from the local port to the remote a goroutine copies data from the remote to the local port data to the TCP connection data from the TCP connection port forwarding, which results in the client streams being closed The problem is that the data written in step 3 is only to the local TCP port. There's no guarantee that the goroutine in 2.i copies the data to the remote before step 5 happens. In fact, if you reverse steps 3 () and 4 () so the write happens immediately before you close the stopChan, this test fails very quickly. I am thinking about how to fix this...
Not done yet:
Saw this again today:
- this was a different failure than this one. I've just opened for it and closing this one
Change:
) func GetDefaultServerImage() string { <del> return fmt.Sprintf("%s:%s", hyperkubeImageName, version.Get()) </del> <ins> return fmt.Sprintf("%s:%s", hyperkubeImageName, strings.Replace(version.Get().String(), "+", "_", 1)) </ins> } func Run() error {

Discussion:
/kind bug What happened: Federation set up using kubefed uses invalid reference format, breaking the Federation control plane. What you expected to happen: That it works. How to reproduce it (as minimally and precisely as possible): Try to set up a control plane using kubefed. Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0+", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-10-02T09:48:25Z", GoVersion:"go1.9", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"7+", GitVersion:"v1.7.6-gke.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-09-27T21:21:34Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration**: GCP OS (e.g. from /etc/os-release): Ubuntu Xenial Kernel (e.g. ): Irrelevant Install tools: GKE
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
Reiterating the mentions to trigger a notification: <detailsIn response to : /sig federation /cc 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
cc might be able to help.
/assign
Assigning to you from the build cop rotation.
the fix for this issue is identified and fixed in . But it will take a while to be available on stable releases. Meanwhile you can use flag to to pass specific hyperkube version.
Change:
) const ( <del> // MaxUint defines the max unsigned int value. MaxUint = ^uint(0) // MaxInt defines the max signed int value. MaxInt = int(MaxUint >> 1) </del> // MaxTotalPriority defines the max total priority value. MaxTotalPriority = int64(math.MaxInt64) // MaxPriority defines the max priority value. MaxPriority = 10 // MaxWeight defines the max weight value. <del> MaxWeight = int64(math.MaxInt64 / MaxPriority) </del> <ins> MaxWeight = MaxTotalPriority / MaxPriority </ins> // DefaultPercentageOfNodesToScore defines the percentage of nodes of all nodes // that once found feasible, the scheduler stops looking for more nodes. DefaultPercentageOfNodesToScore = 50

Discussion:
MaxInt const is exported in scheduler api although it is not needed to be exported. It is only used by . discussed that the common practice is to have API constants in /sig scheduling
cc
The problem is that it is part of a v1 API :(
Ok, it turns out they are not actually considered part of the API, and so we can remove them:
Should I open a PR to address removing those const values from ?
Yes, we can remove those in a followup PR to the one handling sized values.
Yes, this was the plan. /assign
remember to remove as well :)
Change:
return nil, err } domainNameLabel := getPublicIPDomainNameLabel(service) <del> pip, err := az.ensurePublicIPExists(service, pipName, domainNameLabel) </del> <ins> pip, err := az.ensurePublicIPExists(service, pipName, domainNameLabel, clusterName) </ins> if err != nil { return nil, err }

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: We deployed two Kubernetes clusters to the same Azure Resource Group. Created services of load balancer type on both clusters. One of the services never received a public IP. Upon investigation, we noticed that the first Kubernetes cluster deleted the Azure Public IP that was created for the service by the other cluster. Apparently, all public IPs in the resource group are retrieved: then public IPs which don't match this criteria: are deleted. This logic besides the name of the kubernetes service should also consider the K8s cluster where the public IP originated from to avoid stepping on each other's toes when multiple clusters share the same resource group. What you expected to happen: In case multiple clusters run in the same resource group a cluster should delete only resources created by itself. How to reproduce it (as minimally and precisely as possible): Create two Kubernetes clusters (1.14) with different cluster names to the same resource group than create kubernetes services of load balancer type in each cluster. Anything else we need to know?: Environment: Kubernetes version (use ): 1.4 Cloud provider or hardware configuration: Azure OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
thanks for reporting the issue, this is the bug we should fix for sharing resource group. /sig azure /kind bug /assign
Change:
"type": "array" } }, <del> "required": [ "acceptedNames", "storedVersions" ], </del> "type": "object" }, "io.k8s.apiextensions-apiserver.pkg.apis.apiextensions.v1.CustomResourceDefinitionVersion": {

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently, the field on must be explicitly set to their zero-values due to the fact that they are not tagged . Ref: Why is this needed: If using a system that automatically compares the provided configuration to the current, it will produce a diff on the updated status after creation. In addition, making sure to explicitly set to zero-values is not the best user experience. I am happy to provide the fix if this change is approved! /cc /sig api-machinery /area custom-resources
marking them as seems ok, so that client-side validation doesn't complain if they are absent when submitting manifests, but they shouldn't need to be set to omitempty (and at this point, we likely wouldn't change the serialization) Those fields are changed by controllers after creation, so expecting the live API object to exactly match the status is not going to go well anyway.
Good point! I’ll open a fix for this. Yep! The specific system in question ignores fields that are not set at creation time by default when doing comparison, so if status fields are not included then it will not report a diff.
/assign
I opened a fix for this but CC'ed both you and Let me know if any additional effort is required. Thanks!