jiebi/CodeConvo huggingface dataset:
Change:
def := ing.Spec.DefaultBackend ns := ing.Namespace if def == nil { <del> // Ingresses that don't specify a default backend inherit the // default backend in the kube-system namespace. def = &networkingv1.IngressBackend{ Service: &networkingv1.IngressServiceBackend{ Name: "default-http-backend", Port: networkingv1.ServiceBackendPort{ Number: 80, }, }, } ns = metav1.NamespaceSystem </del> <ins> w.Write(LEVEL_0, "Default backend:t<default>n") } else { w.Write(LEVEL_0, "Default backend:t%sn", i.describeBackendV1(ns, def)) </ins> } <del> w.Write(LEVEL_0, "Default backend:t%sn", i.describeBackendV1(ns, def)) </del> if len(ing.Spec.TLS) != 0 { describeIngressTLSV1(w, ing.Spec.TLS) }

Discussion:
I ran on a fresh minikube with no other services in it and saw this output. Which suggests there is a service in the cluster called (there isn't), and further suggests there is something wrong (there isn't) because there are no endpoints found. I expected to provide me with an accurate description of my Ingress object. This behaviour appears to be hardcoded into the kubectl describe command. Which contains a comment suggesting that this is default behaviour, but no logic to check if the service actually exists before attempting to default to it. <details</details<details</details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions 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 cli
See also do you know the history here?
not beyond what shows: Looks like an (incorrect) assumption in the describer that the only implementation would behave in this way
/assign
work in progress...
when you get the PR up please link this issue and in it and ping me directly on slack to get a fast review. I agree with what was stated here and in the other issue, that this seems like an unnecessary assumption that should've not been there, we probably should just leave it empty or per print as the value.
Change:
if preemptor.Spec.NodeName != test.runnningNode { t.Errorf("Expect pod running on %v, got %v.", test.runnningNode, preemptor.Spec.NodeName) } <del> pods = append(pods, preemptor) // cleanup defer testutils.CleanupPods(cs, t, pods) cs.CoreV1().Nodes().DeleteCollection(context.TODO(), metav1.DeleteOptions{}, metav1.ListOptions{}) </del> }) } }

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Integration tests are sometimes flaking locally: PreferNominatedNode Once the node gets deleted, the nodelifecycle controller is racing to update pod status and the pod deletion logic is failing causing tests to flake. Ultimately, we call testCtx.CleanUp() which cleans the nodes and the pods involved the test namespace so we are not going to leak any resources. links to appreciated links to specific failures in spyglass appreciated <!-- You can identify the SIG from the "prowjobconfigurl" on the testgrid dashboard for a test --/sig scheduling <!-- Please see the deflaking doc () for more guidance! --/assign
cc Tried addressing it via
/triage accepted thanks!
Change:
return instances, nil } <del> func (gce *GCECloud) GetZone() (string, error) { return gce.zone, nil </del> <ins> func (gce *GCECloud) GetZone() (Zone, error) { region, err := getGceRegion(gce.zone) if err != nil { return Zone{}, err } return Zone{ FailureDomain: gce.zone, Region:        region, }, nil } // gce zone names are of the form: ${region-name}-${ix}. // For example "us-central1-b" has a region of "us-central1". // So we look for the last '-' and trim to just before that. func getGceRegion(zone string) (string, error) { ix := strings.LastIndex(zone, "-") if ix == -1 { return "", fmt.Errorf("unexpected zone: %s", zone) } return zone[:ix], nil </ins> }

Discussion:
Comments that the PR bot adds solely to trigger email notification of a label change, should be immediately deleted by the bot after it adds them. I have no idea what team to assign this to... cc/
, David Oppenheimer wrote:
(Motivation, of course, is to avoid having PR threads that are 90% bot comments...)
should really be an issue over in that's where (some of) the bots live. Lets make a list of which comments we want deleted immediately. [x] Label size. [x] Needs rebase. [x] test this stale CI [x] test this pending CI [x] PR changed after LGTM, removing LGTM. [x] Comment about blocking based on the paths touched (old docs) [x] unapproved cherrypick comment [x] cherrypicks must set a milestone [x] ok to test from bot I don't want to make it all comments. There are way too many times people have asked me "Why did the bot add 'do-not-merge'?" and I can just link them the comment 2 lines above which tells exactly why....
"Test this" with an issue is also useful, isn't it? On Apr 7, 2016 6:30 PM, "Eric Paris" wrote:
OK to test Add to whitelist On Apr 7, 2016 6:30 PM, "Eric Paris" wrote:
I was envisioning deleting the by the bot. (every 48 hours after LGTM, when retesting right before merge) not those by users (with an issue) After LGTM the bot will add , that one I can remove. The request to comes from the jenkins bot. And in that I am clueless...
any interest in a review (I'm trying to not just self merge all my own bot changes). This deleted hundreds and hundreds of comments.
Looks like reviewed it since your last message:

The contains instructions for downloading kubectl. The doesn't contain these instructions but it should if it's now the recommended way of running Kubernetes locally.
+1 Just ran into this.
cc
By the way, we encourage anyone to propose improvements/fixes to docs. You can do so pretty easily by clicking the pencil icon in the top right corner of every page of
kubectl download instructions to the guide in
Change:
"//staging/src/k8s.io/apimachinery/pkg/util/uuid:go_default_library", "//staging/src/k8s.io/legacy-cloud-providers/azure:go_default_library", "//test/e2e/framework:go_default_library", <ins> "//vendor/github.com/Azure/azure-sdk-for-go/services/compute/mgmt/2019-07-01/compute:go_default_library", </ins> ], )

Discussion:
I am trying to run Azure e2e tests: The test creates a volume in the cloud + runs a pod with the volume as in-line. The pod never starts: The test creates a "blob" disk, while the Azure machine expects "managed" disk. Does anyone run storage e2e tests on Azure regularly? Was it ever working? Managed disks are provisioned . Should the test suite create "managed" disks by default too? Environment: Kubernetes version (use ): v1.17.0-alpha.0.1089+-dirty
/sig azure
/sig cloud-provider
managed disk should be the default, the azure disk storage class in the test case may have
The volume is created outside of kubernetes dynamic provisioning to test pre-provisioned and inline volumes: I wonder if anyone actually runs the tests.
Change:
} return false, err }) <del> if err != nil { framework.DescribeSvc(namespace) framework.Failf("Error in deleting service %s: %v", serviceName, err) } </del> <ins> return err </ins> } func cleanupServiceShardsAndProviderResources(namespace string, service *v1.Service, clusters fedframework.ClusterSlice) {

Discussion:
In order to support running tests in parallel, we randomized NodePort selection. There appears to be some evidence that this is not sufficient and is causing e2e test flakes: https://k8s-
Hi, As a need contributor, I'm interesting of solving this issue. I already check the current code, and propose to retry the service creation until success or all possible ports (between FederatedSvcNodePortFirst and FederatedSvcNodePortLast) have been tried. If this approach is fine for you, I can submit a PR soon.
How do you plan to check if the NodePorts are available? In our presubmit test environment, tests run across many instances of federation control planes in parallel, but share the same underlying clusters. So this approach might be viable depending on how and where you plan to check for these used NodePorts.
my approach for getting an available port is a "Dummy" approach: create a list of possible available port, get one of them randomly, then try to create the Service. If Service creation failed. try to use another possible available port, until service creation success or all possible available ports have been tested.
Sounds reasonable to me. Go for it. A couple of caveats: need to create a real list, you could just use the range boundaries. careful about service creation failure. You need to check if the service shard creation failed in the underlying clusters and rollback all those shards before retrying.
thanks for the caveats, I will do soon a PR.
Hi, what is the state of this issue? Is working in this issues with the others issues related to e2e tests?
has a PR to fix this issue -
Change:
return notReadyNodes, stateNormal } } <del> // maybeDeleteTerminatingPod non-gracefully deletes pods that are terminating // that should not be gracefully terminated. func (nc *Controller) maybeDeleteTerminatingPod(obj interface{}) { pod, ok := obj.(*v1.Pod) if !ok { tombstone, ok := obj.(cache.DeletedFinalStateUnknown) if !ok { glog.Errorf("Couldn't get object from tombstone %#v", obj) return } pod, ok = tombstone.Obj.(*v1.Pod) if !ok { glog.Errorf("Tombstone contained object that is not a Pod %#v", obj) return } } // consider only terminating pods if pod.DeletionTimestamp == nil { return } node, err := nc.nodeLister.Get(pod.Spec.NodeName) // if there is no such node, do nothing and let the podGC clean it up. if apierrors.IsNotFound(err) { return } if err != nil { // this can only happen if the Store.KeyFunc has a problem creating // a key for the pod. If it happens once, it will happen again so // don't bother requeuing the pod. utilruntime.HandleError(err) return } // delete terminating pods that have been scheduled on // nodes that do not support graceful termination // TODO(mikedanese): this can be removed when we no longer // guarantee backwards compatibility of master API to kubelets with // versions less than 1.1.0 v, err := utilversion.ParseSemantic(node.Status.NodeInfo.KubeletVersion) if err != nil { glog.V(0).Infof("Couldn't parse version %q of node: %v", node.Status.NodeInfo.KubeletVersion, err) utilruntime.HandleError(nc.forcefullyDeletePod(pod)) return } if v.LessThan(gracefulDeletionVersion) { utilruntime.HandleError(nc.forcefullyDeletePod(pod)) return } } </del>

Discussion:
As discussed on slack with we might want to clean the node controller from code that ensures backward compatibility for version 1.4 and earlier ones. /sig node
/assign
- how do we plan to devide this one ? The following order for merge should be fine I think: the tests (we can split also test case deletion if it's too long to review): logic itself + kubeletVersion on the according tests: change how we create nodecontroller: clean consts and BUILD:
Yeah, sounds good.
I'll create the PRs accordingly and assign them to you
Change:
cc := &CertificateController{ kubeClient: kubeClient, <del> queue:      workqueue.NewNamedRateLimitingQueue(workqueue.DefaultControllerRateLimiter(), "certificate"), handler:    handler, </del> <ins> queue: workqueue.NewNamedRateLimitingQueue(workqueue.NewMaxOfRateLimiter( workqueue.NewItemExponentialFailureRateLimiter(200*time.Millisecond, 1000*time.Second), // 10 qps, 100 bucket size.  This is only for retry speed and its only the overall factor (not per item) &workqueue.BucketRateLimiter{Bucket: ratelimit.NewBucketWithRate(float64(10), int64(100))}, ), "certificate"), handler: handler, </ins> } // Manage the addition/update of certificate requests

Discussion:
Each node waiting for bootstrapping creates 1 line per 2-3s in the logs when the requesting client doesn't have access. It should not be logging at v(0), these are all v(4) level. We should be reporting these appropriately. I don't want a 5k node cluster showing this.
I'd like to fix it
Change:
"k8s.io/kubernetes/pkg/scheduler/framework/plugins/feature" "k8s.io/kubernetes/pkg/scheduler/framework/plugins/names" schedutil "k8s.io/kubernetes/pkg/scheduler/util" <ins> "k8s.io/utils/ptr" </ins> ) const (

Discussion:
/kind failing-test /kind flake /sig node /assign
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions 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
Change:
"k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/schema" <ins> "k8s.io/apimachinery/pkg/selection" </ins> "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/intstr" "k8s.io/apimachinery/pkg/util/sets"

Discussion:
master-blocking Conformance - GCE - master - kubetest2Kubernetes e2e suite. ci-kubernetes-gce-conformance-latest-kubetest2.Overall kubetest2.Test ! 2023-06-27 16:43 PDT Kubernetes e2e suite: [It] [sig-apps] Daemon set [Serial] should rollback without unnecessary restarts [Conformance] No response /sig cloud-provider /sig apps cc
This is more critical than I expected it starts to fail in other jobs ,%20master ,%20ipvs,%20dual,%20master From the diff the best candidate seems can you PTAL /priority critical-urgent
/assign
anyone from you can please add to this issue?
/triage accepted
I have a proposed fix in . Is there a job I can add?
/remove-kind failing-test /kind flake
Change:
"pods": "10", "services": "5", "replicationcontrollers":"20", <del> "resourcequotas":"1", }, </del> <ins> "resourcequotas":"1" } </ins> } } EOF

Discussion:
I'm following step by step tutorial on how to create resource quotas per namespace () looks like this: { "apiVersion": "v1", "kind": "ResourceQuota", "metadata": { "name": "quota", }, "spec": { "hard": { "memory": "1Gi", "cpu": "20", "pods": "10", "services": "5", "replicationcontrollers":"20", "resourcequotas":"1", }, } when i'm about to create quota it fails with: kubectl create -f --namespace=prod invalid character '}' looking for beginning of object key string Namespace "prod" exists: kubectl get namespace NAME LABELS STATUS AGE default &lt;noneActive 26d dev name=development Active 8d kube-system &lt;noneActive 26d prod name=production Active 8d kubectl version Client Version: version.Info{Major:"1", Minor:"1", GitVersion:"v1.1.2", GitCommit:"", GitTreeState:"clean"} Server Version: version.Info{Major:"1", Minor:"1", GitVersion:"v1.1.2", GitCommit:"", GitTreeState:"clean"}
Those trailing commas are wrong. should look like: I'll submit a docs patch
sweet. ta. That seem to do the trick: kubectl create -f --namespace=prod resourcequota "quota" created
I'm going to reopen until the PR which fixes this merges, when it should autoclose...
I'm following this tutorial on installing percona with kubectl, and I'm getting a similar error: When I run: kubectl create -f pmm-server- I get: error: json: line 1: invalid character ‘Â’ looking for beginning of object key string
Change:
kubectl create -f test/fixtures/pkg/kubectl/cmd/create/sar-v1beta1.json --validate=false SAR_RESULT_FILE="${KUBE_TEMP}/sar-result.json" <del> curl -kfsS -H "Content-Type:" --oauth2-bearer admin-token "https://localhost:${SECURE_API_PORT}/apis/authorization.k8s.io/v1beta1/subjectaccessreviews" -XPOST -d @test/fixtures/pkg/kubectl/cmd/create/sar-v1beta1.json > "${SAR_RESULT_FILE}" </del> <ins> curl -kfsS -H "Content-Type:" -H 'Authorization: Bearer admin-token' "https://localhost:${SECURE_API_PORT}/apis/authorization.k8s.io/v1beta1/subjectaccessreviews" -XPOST -d @test/fixtures/pkg/kubectl/cmd/create/sar-v1beta1.json > "${SAR_RESULT_FILE}" </ins> if grep -q '"allowed": true' "${SAR_RESULT_FILE}"; then kube::log::status ""authorization.k8s.io/subjectaccessreviews" returns as expected: $(cat "${SAR_RESULT_FILE}")" else

Discussion:
What happened: After running ./hack/update-openapi- with the latest code, api/openapi- file became empty even when no changes were made in the code. What you expected to happen: After running ./hack/update-openapi- with the latest code, api/openapi- file should not be changed when no changes were made in the code. When I tried the same thing a few week back, I didn't encounter this problem. How to reproduce it (as minimally and precisely as possible): Download the latest kubernetes/kubernetes code and run the following script to update openapi spec. api/openapi- became empty after this. Anything else we need to know?: There's a line in update-openapi- that runs a curl command . This line was changed a few days ago by this commit: PR: I checked out the commit before and ran /update-openapi- It works. is not empty any more. Is there any new setting required before running ./hack/update-openapi- now? Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery
cc
Hi, thanks for the report, but it is a bit weird that I could not reproduce locally: and besides, completes successfully on my machine. Could you reproduce?
Someone else also ran into this same problem and asked a question on sig-api-machinery slack yesterday. So I'm not the only one who ran into this.
could you change the args passed to curl in to and rerun the script to see if there is any error?
since it is already late here(UTC+8), I would check this issue again tomorrow
I was the "someone else" who ran into this problem :) I changed the script to use The result: Actually, it was 403 without the "S", too, but that is visible only if curl is executed in verbose mode.
Hi, thanks for your information. Given that the apiserver returned 403, I suspect the flag passed to curl has no effect in your environment, would you mind posting the output of ? I am using curl 7.64.1: In addition, I think you could try changing the curl command in to the following: and see if the problem is solved.

I tried the following and it worked for me. is no longer empty. curl version:
Thanks for your confirmation, and I have filed to address this issue.
I can confirm, it works with the changed curl command.
/triage accepted
Change:
return !ok || endpointSlice.Generation > g } <del> // StaleSlices returns true if one or more of the provided EndpointSlices // have older generations than the corresponding tracked ones or if the tracker // is expecting one or more of the provided EndpointSlices to be deleted. </del> <ins> // StaleSlices returns true if any of the following are true: // 1. One or more of the provided EndpointSlices have older generations than the //    corresponding tracked ones. // 2. The tracker is expecting one or more of the provided EndpointSlices to be //    deleted. // 3. The tracker is tracking EndpointSlices that have not been provided. </ins> func (est *endpointSliceTracker) StaleSlices(service *v1.Service, endpointSlices []*discovery.EndpointSlice) bool { est.lock.Lock() defer est.lock.Unlock()

Discussion:
The controllers can create a second EndpointSlice after an immediate sync if the first EndpointSlice they created is not in the cache yet. Here's what can happen: gets event that triggers sync for Service syncs and creates EndpointSlice gets event that triggers sync for same Service syncs and creates EndpointSlice (the slice created in 2 has not made it to the cache yet) A single EndpointSlice to be created. Run integration tests hundreds of times that involve 2 consecutive events that will trigger a sync. Example: /assign /sig network
/triage accepted
/cc
When this bug is fixed, we'll need to rollback
just amend it in the PR that fix the bug, so we merge all together
Change:
health kubernetes $DNS_DOMAIN in-addr.arpa ip6.arpa { pods insecure <ins> upstream </ins> fallthrough in-addr.arpa ip6.arpa ttl 30 }

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-serial Which test(s) are failing: [sig-network] DNS configMap nameserver [IPv4] Forward external name lookup should forward externalname lookup to upstream nameserver [Slow][Serial] Since when has it been failing: Failing since 6/10 at 16:58. . Decent chance that the failure is due to Testgrid link: Reason for failure: /cc /priority critical-urgent /kind failing-test /milestone v1.15 /cc
This is blocking the release /cc
I noticed in the it thinks it's testing 1.16 alpha:
/assign
should fix it. Sorry for the mess-up!
Change:
} for _, ingress := range service.Status.LoadBalancer.Ingress { <del> info.loadBalancerIngressIPs = append(info.loadBalancerIngressIPs, &loadBalancerIngressInfo{ip: ingress.IP}) </del> <ins> if net.ParseIP(ingress.IP) != nil { info.loadBalancerIngressIPs = append(info.loadBalancerIngressIPs, &loadBalancerIngressInfo{ip: ingress.IP}) } </ins> } return info }

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 --- Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions 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 network
/sig windows