jiebi/CodeConvo huggingface dataset:
Change:
return tabbedString(func(out io.Writer) error { w := NewPrefixWriter(out) w.Write(LEVEL_0, "Name:t%sn", node.Name) <ins> w.Write(LEVEL_0, "Role:t%sn", findNodeRole(node)) </ins> printLabelsMultiline(w, "Labels", node.Labels) printAnnotationsMultiline(w, "Annotations", node.Annotations) printNodeTaintsMultiline(w, "Taints", node.Spec.Taints)

Discussion:
used to show masters, but as of it no longer does. This is not in accordance with our deprecation policy I believe. cc
That commit/PR is not relevant as there are no supported users/deployment methods that are using label. kubeadm v1.4 or v1.5 was the last. What you're really looking for is who/what removed printing things based on the label...
No blame on you The regression is that we have stopped printing masters in . There may be more to it that a simple revert of , but we should probably start there.
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. 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
This has been fixed in recent versions
Change:
cset := m.state.GetCPUSetOrDefault(string(pod.UID), container.Name) if cset.IsEmpty() { // NOTE: This should not happen outside of tests. <del> klog.InfoS("ReconcileState: skipping container; assigned cpuset is empty", "pod", klog.KObj(pod), "containerName", container.Name) </del> <ins> klog.V(4).InfoS("ReconcileState: skipping container; assigned cpuset is empty", "pod", klog.KObj(pod), "containerName", container.Name) </ins> failure = append(failure, reconciledContainer{pod.Name, container.Name, containerID}) continue }

Discussion:
kubernetes 1.19.2 seeing tons of these, feels like something that should be debug or info ... not really actionable or something that it should warn about ? /sig node
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
I am also seeing this same issue what's odd is that I cannot find the container it's looking for which is probably why its giving this message, so my question would be why is it looking for this container ID?
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-contributor-experience at . /lifecycle stale
/lifecycle frozen
I agree this should be lower than warning... /triage accepted /help
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 : I agree this should be lower than warning... /help 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
I think all InfoS messages under the should be moved to debug messages because it flood the log when the CPU manager enabled with the static policy.
/assign
Change:
if apipod.UpdatePodCondition(newStatus, condition) { if err := util.PatchPodStatus(ctx, cs, victim, newStatus); err != nil { klog.ErrorS(err, "Preparing pod preemption", "pod", klog.KObj(victim), "preemptor", klog.KObj(pod)) <del> return framework.AsStatus(err) </del> <ins> errCh.SendErrorWithCancel(err, cancel) return </ins> } } } if err := util.DeletePod(ctx, cs, victim); err != nil { klog.ErrorS(err, "Preempting pod", "pod", klog.KObj(victim), "preemptor", klog.KObj(pod)) <del> return framework.AsStatus(err) </del> <ins> errCh.SendErrorWithCancel(err, cancel) return </ins> } } fh.EventRecorder().Eventf(victim, pod, v1.EventTypeNormal, "Preempted", "Preempting", "Preempted by %v/%v on node %v", pod.Namespace, pod.Name, c.Name()) } <ins> fh.Parallelizer().Until(ctx, len(c.Victims().Pods), preemptPod, ev.PluginName) if err := errCh.ReceiveError(); err != nil { return framework.AsStatus(err) } </ins> metrics.PreemptionVictims.Observe(float64(len(c.Victims().Pods))) // Lower priority pods nominated to run on this node, may no longer fit on

Discussion:
When a pod requires preempting more than one pod, this happens sequentially. It should be done in parallel. /sig scheduling /sig scalability Preemption happens in the scheduling cycle, meaning that no other scheduling attempts happen while preemption is ongoing, hurting throughput. An alternative is to the deletes in a separate routine, like we do for binding.
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
cc
I'm a newbie, may I have a try at this proposal?
Yes, this is a good candidate for new contributors. However, I would like to hear from SIG scalability whether there are any concerns about this.
Parallelizing the loops looks like the easier option to implement, but deleting in a separate routine will likely offer the better throughput for the average case.
Parallelizing loops seems fine from SIG Scalability perspective - we already do something similar for example in KCM when creating pods or in scheduler each binding is done by separate goroutine. One question though, is there a limit of pods that we want to preempt here? 100 parallel calls will be probably fine, but 1000 wouldn't be most likely.
We only preempt pods from a single node, so that's a natural threshold. And we have a parallelizing mini-library that has 16 workers by default.
Hi, do you still want to work on this one?
YesIt's still under discussion.
So we can use the parallelizing mini-library to do this?
You can use this parallelizer we defined in scheduler framework directly.
feel free to take it by writing on a comment.
/assign
Change:
### Cluster Created by Kubeadm <del> If you are using kubeadm with a [configuration file](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file), you have to add `mode: ipvs` and also add `SupportIPVSProxyMode: true` below the `kubeProxy` field as part of the kubeadm configuration. </del> <ins> If you are using kubeadm with a [configuration file](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file), you have to add `mode: ipvs` below the `kubeProxy` field as part of the kubeadm configuration. </ins> ```yaml ... kubeProxy: config: <del> featureGates: SupportIPVSProxyMode: true </del> mode: ipvs ... ``` <del> Note that in Kubernetes 1.11 and later, `SupportIPVSProxyMode` is set to `true` by default. </del> before running `kube init --config <path_to_configuration_file>` <del> If you are using Kubernetes v1.8, you can also add the flag `--feature-gates=SupportIPVSProxyMode=true` (deprecated since v1.9) in `kubeadm init` command ``` kubeadm init --feature-gates=SupportIPVSProxyMode=true ``` </del> to specify the ipvs mode before deploying the cluster. **Notes**

Discussion:
When should it be removed? /sig network /kind cleanup
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
Feature is GA since 1.11 - Any reference to this Feature Gate needs to be removed from the code, README and Docs: If you're a new contributor, please step in, take this issue, make the PRs, assign it to me with /assign and I'll be glad to help you through the journey of contributing :) /good-first-issue /help
This request has been marked as suitable for new contributors. 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 : Feature is GA since 1.11 - /help 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
/assign
are you willing to take this one?
Yes. I'm a new contributor.I will to try to complete it.
/assign Welcome! Let me know if you need any kind of help. Please take a look also into the Kubernetes Contributors documentation - When you're ready to create your first PR, please assign it to me and I'll make the first pass!
/sig docs We don't remove GA feature gates from the website; we move them to
Change:
<ins> apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: examples.test.com spec: group: test.com scope: Cluster versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: test: type: string names: plural: examples singular: example kind: Example </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 --Changing the scope field of a CRD ist not possible since it's immutable. But even after deleting and re-creating the CRD with changed scope it doesn't let me create resources of the CRD's kind. Re-creating CRD with changed scope should just work. Here is a full example that in the end leads to the error when trying to create a resource after re-creating the CRD. Kubernetes version (use ): v1.21.4 Cloud provider or hardware configuration: vSphere 7.0 OS (e.g: ): Centos 7 Kernel (e.g. ): 3.10.0-1160.42.2.el7.x86_64
/sig api-machinery
/assign /triage accepted
This appears to be working as intended. The example custom resource you use: It Cluster scoped because it has no namespace. But once the CRD is namespace scoped, you should not be able to create cluster scoped custom resources of that type. If instead you add a namespace to Example, it should be created, e.g.:
if the above seems to have answered your question - please feel free to close the issue :) Thank you!
kubectl will automatically use the namespace so this is definitely not the issue here. I can reproduce this issue with my above script in a fresh (v1.22.2) cluster. You can add the namespace in the last manifest, it makes no difference. From my understanding this really seems to be a bug.
Yes, that's true. Good catch. Okay, we need to root cause this.
I tried using curl to create the custom resource directly against the API and got the same result: So the problem seems to be in the API server (not in kubectl).
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
Change:
KubeletConfig              client.KubeletConfig ClusterName                string EnableProfiling            bool <ins> MaxRequestsInFlight        int LongRunningRequestRE       string </ins> } // NewAPIServer creates a new APIServer object with default parameters

Discussion:
Related with issue , the API server should have a cap on the number of outstanding operations/requests it's handling, and return an error otherwise. A simple semaphore is an idea for this.
+1 !
The good news/bad news on this is that there is a rate limiter in the API server (), but the defaults for it seem too high: 10 qps average, 200 burst (). We could start by lowering the burst level to something smaller, like 30. It may be interesting to also differentiate between GET and PUT/POST requests.
I think that we need limits on the number of outstanding requests, not the number of QPS.
-An max outstanding would be useful. But it may force us to have separate buckets for different types of requests, i.e. a small number of long running requests causing API server to reject short requests. -Heard that you might be looking into adding support for flow control (or something like it?). We may need it soon to help avoid bugs like runaway node status updates (see issue ).
I had not - the things we were looking at were the bastion changes to apiserver which will break logs and proxying into their own rest resources so they can be granularly controlled. Being able to timebox and classify requests differently would be good. ----- Original Message -----
- Ah, np, I probably misheard.
What are our plans for handling this client side? Do we want clients to handle "you're being throttled" error themselves, or do we plan to handle it in the library? I'm asking because currently kubelet does not have a 'short' retry loop, hence it tries to report NodeStatus every X (2) seconds, whether it succeed or not. Neither we have a sidechannel for heartbeat messages. This would mean, that if API server will be under heavy load, and with not-negligible probability NodeStatus reporting will be throttled, we may incorrectly mark a Node as unreachable. Currently it's not a huge problem, because X << Y, where Y is the time we wait before we decide a Node is unreachable. But because of the effort somewhere close to it'll probably get worse.
The client library should have options for retry on client.Config which include the ability to disable the behavior. Automatic retry is probably an "opt-out" behavior.

----- Original Message -----
says there are people working on rate limiting client connections to API server.
I have in the past adjusted the rate limiter to support the creation of large clusters. I also the logic. If you adjust the rate limiter settings, please make sure it is still possible to create large clusters.
I'm closing this as fixed, given the original subject. If we want to expand client-side support for retry, please open a dedicated issue. (Also note that QPS based throttling was to the client recently too)
Change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/util/intstr" <ins> "k8s.io/apimachinery/pkg/util/wait" </ins> "k8s.io/client-go/informers" "k8s.io/client-go/kubernetes/fake" k8stesting "k8s.io/client-go/testing"

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: Mistake use obj as prevObj prevEndpointSlice := obj.(discovery.EndpointSlice) What you expected to happen: prevEndpointSlice := prevObj.(discovery.EndpointSlice) How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: 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: cc
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved PR for fixing it Thanks
Change:
verbs: - delete - update <ins> - apiGroups: - "" resources: - pods/finalizers verbs: - update </ins> - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata:

Discussion:
When OwnerReferencesPermissionEnforcement admission plugin is used the PVCs are not deleted and KCM logs show PVCs should have ownerReferences set and the PVCs should be garbage collected on scale down 3 of 6 of the following tests fail when OwnerReferencesPermissionEnforcement admission plugin is turned on No response <details</details<detailsNA </details<details</details<details</details<details</details<details</details
/sig apps /triage accepted
Change:
# Post-Condition: Wait failed kube::test::if_has_string "${output_message}" 'timed out' <ins> # wait with mixed case jsonpath output_message=$(kubectl wait --for=jsonpath=.status.unavailableReplicas=1 deploy/test-1 2>&1) # Post-Condition: Wait failed kube::test::if_has_string "${output_message}" 'test-1 condition met' </ins> # Delete all deployments async to kubectl wait ( sleep 2 && kubectl delete deployment --all ) &

Discussion:
In v1.31.0-rc.1 commands hang, see relevant thread for details. Second command should work, as it does with kubectl v1.30.3 Reproducer against a 1.30.3 server: No response <details</details<details</details<details</details<details</details<details</details<details</details
cc
looks like a regression introduced in /assign
thanks so much for the very detailed and timely report, great to catch this before the .0 release
Change:
wantReason string } testCases := []struct { <del> short       bool </del> featureGate bool create      step update      step

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-kubernetes-integration-master I can't seem to find a match for beyond that? Most likely related to as it was merged during that set of commits Example Spyglass link: /cc /sig apps /priority critical-urgent /milestone v1.21
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
/assign
FYI: the error message is a red herring and isn't the real reason why this test is failing. When the integration tests are run with instead of , the mutation detector is also started, which catches a bug in the job controller where we modify the shared cache. This root cause isn't present in the logs, but you can reproduce this bug with the following command: Then apply the job controller patch in and re-run the test, you'll see that the test passes. You'll also notice that passes with/without the bug fix patch when run with . cc
Test is back on green. Thanks !
Change:
Hostname: "pod-1", }}, }}, <ins> uid: "d8f2c1f6-5285-4b3c-b3c1-9b89f9e7ed7a", </ins> existingEndpointSlices: []*discovery.EndpointSlice{{ ObjectMeta: metav1.ObjectMeta{ <del> Name: "test-ep-1", </del> <ins> Name:      "test-ep-1", Namespace: "test", OwnerReferences: []metav1.OwnerReference{ { APIVersion: "v1", Kind:       "Endpoints", Name:       "test-ep", UID:        "d8f2c1f6-5285-4b3c-b3c1-9b89f9e7ed7a", }, }, </ins> }, AddressType: discovery.AddressTypeIPv4, Ports: []discovery.EndpointPort{{

Discussion:
create a service without selector, and manual create endpoints for this service endpointslicemirroring controller will create an endpointslice for this service. after endpoint slice created, and kube-controller-manager restart. during the kube-controller-manager restart, the endpoint was deleted and recreated after kube-controller-manager restart, garbagecollector controller delete this endpointslice and endpointslice not recreate until endpoint/service update event or kube-controller-manager restart endpointslice will be recreated create a service without selector, and manual create endpoints for this service endpointslicemirroring controller will create an endpointslice for this service. after endpoint slice created, and kube-controller-manager restart. during the kube-controller-manager restart, the endpoint was deleted and recreated No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig network
/assign
Trying to understand this, mostly just restating what you've said above to make sure I'm getting it: during the kube-controller-manager restart, the endpoint was deleted and recreated after kube-controller-manager restart, garbagecollector controller delete this endpointslice and endpointslice not recreate until endpoint/service update event or kube-controller-manager restart So an Endpoints resource is being deleted while kube-controller-manager is not running. The EndpointSlice mirroring controller to point to the Endpoints they're mirroring. When kube-controller-manager is restarted, the garbage collector will delete the mirrored EndpointSlice because it's owned by an Endpoints resource that was previously deleted. That deletion by garbage collection would then be , but if the EndpointSliceTracker doesn't think it should have that resource, it will ignore the deletion and not reconcile, resulting in the mirrored EndpointSlice not being recreated until something updates the Service or Endpoints resource.
/triage accepted
Change:
"sync/atomic" v1 "k8s.io/api/core/v1" <del> apierrors "k8s.io/apimachinery/pkg/api/errors" </del> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/client-go/util/workqueue" "k8s.io/kubernetes/pkg/scheduler/algorithm/predicates"

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: This switches NodeLister to scheduler cache for . However, the new implementation in the cache never returns IsNotFound error any more. Rather, it returns a normal error: However, we rely on the error type for logging, for example: What you expected to happen: The cache should return IsNotFound error if applicable. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: /sig scheduling cc
/help
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 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
/good-first-issue
This request has been marked as suitable for new contributors. 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 : /good-first-issue 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'd like to work on this for #Hacktoberfest, and for my very first open-source contribution.
Hello, I would love to contribute too in case. I'm already looking at the code in fact :D
Thanks all for the interest, will assign to since he expressed interest first. /assign
I was browsing around the rest of the implementation of the cache and noticed that none of the other accessors return . Also, I couldn't determine if ever returned anything other than an . I'm new here, so I may be doing it wrong. Are you sure the behavior changed, and are you sure returning is expected? Should the other accessors be changed, too?
Let's look at previous release. The object is initialized in [] where it creates a .

Now let's take a look at implementation: There you can see that it calls NodeLister Get() method, which can return a IsNotFound error.
Hello, is this issue being solved ? If not, i am interested in solving this issue.
Thanks but I am working on this currently.
, if you haven't started your work yet, let me know if I can raise a PR for this issue. I have the change ready.
I started, but haven’t been able to finish creating the PR. Go ahead and submit yours. Thanks. Sent from my iPhone