jiebi/CodeConvo huggingface dataset:
Change:
ErrCodeResourceVersionConflicts: "resource version conflicts", ErrCodeInvalidObj:               "invalid object", ErrCodeUnreachable:              "server unreachable", <del> ErrCodeTimeout:                  "request timeout", </del> } func NewKeyNotFoundError(key string, rv int64) *StorageError {

Discussion:
various Oct 30 2023 6pm pst No response Looks like different test are failing with connection timeout errors: One of the tests triggered a core dump: No response /sig
are both suffers from pkg/registry and is from compoent-base, which likely same reason from `
/retitle failing-test: pkg/kubelet/eviction TestManagerWithLocalStorageCapacityIsolationOpen
/sig node
TestManagerWithLocalStorageCapacityIsolationOpen only failed in one of the PRs, so I don't think that specific test is the problem.
ok, rename as see fit. just put owning sigs please for triage.
TestStoreDeleteCollectionWithContextCancellation is the one that seems to be failing across all the failing PRs, so let's start there first. /retitle failing-test: TestStoreDeleteCollectionWithContextCancellation /sig api-machinery
triage link at shows this just starting (happening in CI jobs as well)
image used in the unit test job didn't change around the timeframe this was seen ()
looking for jumps in package unit test runtimes when this failure started happening to see if something is taking longer or stressing the system: ! - cc ! - cc ! - cc Could any of those have introduced changes that could be stressing or exhausting listener connections in unit tests?
the PR in question introduced a poll function around an API call that is unit tested with a fake client i.e. the poll is unit tested, but the fake client has reactors that return error or success right away, so in theory the poll should not be stretched to 1 retries with 1 connection attempts per fake client. while testing locally i did not notice any significant time difference after or the prior i can do some more checks to see what's going on.
merged right at the time the flakes were seen DeleteCollection invokes List, which was modified in that PR to cancel more aggressively cc
I can reproduce about a 10-20% flake rate at HEAD with: failures look like: or while testing that package with , I see ~1300-1500 open connections with this:
Let's revert it then. I looked into it and I don't know from a quick glance why it's failing and I don't have time to debug it now.

I opened
Okay, it looks like we need more debugging to open this PR
one optimization to strip some ~40 fake client connections and 2 seconds from a test:
sounds good, pointed at that commit as well
/triage accepted
Change:
definitions MUST be published for custom resource definitions. release: v1.16 file: test/e2e/apimachinery/crd_publish_openapi.go <ins> - testname: Discovery, confirm the groupVerion and a resourcefrom each apiGroup codename: '[sig-api-machinery] Discovery should locate the groupVersion and a resource within each APIGroup [Conformance]' description: A resourceList MUST be found for each apiGroup that is retrieved. For each apiGroup the groupVersion MUST equal the groupVersion as reported by the schema. From each resourceList a valid resource MUST be found. release: v1.28 file: test/e2e/apimachinery/discovery.go </ins> - testname: Discovery, confirm the PreferredVersion for each api group codename: '[sig-api-machinery] Discovery should validate PreferredVersion for each APIGroup [Conformance]'

Discussion:
[X] test approval issue : [X] test pr : 3 May 2023 [X] two weeks soak end date : 16 May 2023 [X] test promotion pr : [X] remove endpoint form file According to following two APIsnoop queries, there are still 12 APIResources endpoints that are not tested for Conformance. Using a number of existing e2e test practices a new has been created to address these 12 endpoints. The e2e logs for this test are listed below. This query shows the following apiresources endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 12 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/open For tracking the rest of the processes
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
Change:
// GetModules returns all installed kernel modules. func (handle *LinuxKernelHandler) GetModules() ([]string, error) { <ins> // Check whether IPVS required kernel modules are built-in kernelVersionFile := "/proc/sys/kernel/osrelease" b, err := ioutil.ReadFile(kernelVersionFile) if err != nil { glog.Errorf("Failed to read file %s with error %v", kernelVersionFile, err) } kernelVersion := strings.TrimSpace(string(b)) builtinModsFilePath := fmt.Sprintf("/lib/modules/%s/modules.builtin", kernelVersion) b, err = ioutil.ReadFile(builtinModsFilePath) if err != nil { glog.Errorf("Failed to read file %s with error %v", builtinModsFilePath, err) } var bmods []string for _, module := range ipvsModules { if match, _ := regexp.Match(module+".ko", b); match { bmods = append(bmods, module) } } </ins> // Try to load IPVS required kernel modules using modprobe first for _, kmod := range ipvsModules { err := handle.executor.Command("modprobe", "--", kmod).Run()

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Deploying kube-proxy with mode ipvs on a system with the required ipvs support compiled into the kernel rather than as modules causes the kube-proxy deployment to fall back to using iptables. tryIPVSProxy is only checking for the presence of kernel modules and not if the running kernel has the required support compiled in. What you expected to happen: tryIPVSProxy should succeed if either the required modules are found or support is compiled into the running kernel. How to reproduce it (as minimally and precisely as possible): Boot a system using a kernel with ipvs support compiled in rather than as a module (such as the kernel used by and a host without iptables installed Add --config=/etc/kubernetes/kubelet- to the kubelet arguments using the following kubelet- contents: Install using kubeadm with the following config: Check the output of the kube-proxy pod: Anything else we need to know?: From , it should be possible to check for the existence of modules.builtin and if present use that in addition to using modprobe and the contents of /proc/modules. Environment: Kubernetes version (use ): v1.10.2 Cloud provider or hardware configuration: local kvm host OS (e.g. from /etc/os-release): custom linuxkit build Kernel (e.g. ): Linux linuxkit- 4.14.40-linuxkit SMP Thu May 10 10:06:57 UTC 2018 x86_64 Linux Install tools: kubeadm
/sig network
/cc
cc
cc please take a look.
Change:
cpu: {{hollow_proxy_millicpu}}m memory: {{hollow_proxy_mem_Ki}}Ki - name: hollow-node-problem-detector <del> image: k8s.gcr.io/node-problem-detector:v0.8.0 </del> <ins> image: k8s.gcr.io/node-problem-detector/node-problem-detector:v0.8.5 </ins> env: - name: NODE_NAME valueFrom:

Discussion:
What happened: In a cluster with NPD addon installed and Linux 5.1+ as the kernel OS of the nodes OOMs are not being captured by the NPD. What you expected to happen: NPD should inform about OOMs by emitting appropriate K8s events. How to reproduce it (as minimally and precisely as possible): Create a K8s cluster with NPD addon and Linux 5.1+ installed on the nodes. Schedule a pod which leaks memory. Try to list events with field after an OOM occurs to see there's none. Anything else we need to know?: Fix is already merged into newest (v0.8.5) NPD release: We're currently waiting for the release of Docker image of NPD v0.8.5 - we can proceed with fixing this in k/k afterwards. After it gets merged to the master branch, it should be then cherry-picked to older releases as well. Environment: Any Kubernetes version with NPD addon installed and Linux as the node OS with the kernel version 5.1 or newer.
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 scalability /sig node I opened a fixing PR in but it's on hold since the Docker image of NPD v0.8.5 doesn't exist yet.
Change:
t.Fatalf("unexpected request: %#vn%#v", req.URL, req) return nil, nil } <del> case "PUT": </del> <ins> case "PATCH": </ins> switch req.URL.Path { case "/namespaces/test/pods/foo": return &http.Response{StatusCode: 200, Body: objBody(codec, &pods.Items[0])}, nil

Discussion:
and work in this pattern: first issuing a "GET" to the API server to retrieve the latest object, then adding the label/annotation to the object, and finally issuing an "PUT" with the modified object. The request will fail if the object stored in the server has been updated between the "GET" and "PUT", even if the update has no conflict with the label/annotate request. In such cases, instead of returning an error, should retry without disturbing the end user. There are two ways to implement this: in kubectl: simply retry the label/annotate process several times if the server rejected the request because the object has been updated. The only exception is when the is set, then kubectl shouldn't retry. the strategicMergePatch instead of calling Update at client-side. PATCH is more robust because PATCH does the "get, modify, update" in the server-side, so there is less chance to have a conflict, and PATCH will retry at the server-side (see ). We need to make some adaptions though: kubectl annotate/label has the , when it's false, kubectl should retrieve the latest object to confirm there is no existing annotation/label of the same key, and then proceed with issuing the patch. if the is set, [UPDATE:] we just need to specify the resourVersion in the patch, then it will be treated as a precondition by the UpdateResource() handler in the API server. I plan to take the first approach as an immediate fix.
Immediate need is to fix the flaky e2e test AIUI.
e2e? do we have an issue out there? is an immediate fix to the flake in test-
If this is for 1.1, it needs to be P0 at this point. Should it be?
Fwiw I use annotations both from cmd line as an admin and from scripts, to experiment with loadbalancer settings. In the case of the former, I've never really had a collision, and in the case of the latter my scripts know how to retry like we retry all other updates.
Thank you When used in scripts, the annotate and label commands have collisions frequently, e.g. in the test-, see . IMO, we shouldn't require users to retry in their scripts if we know there is a simple way to avoid the collisions. Anyway, and are sent to fix this.
Change:
docs/man/man1/kubectl-set-image.1 docs/man/man1/kubectl-set-resources.1 docs/man/man1/kubectl-set-selector.1 <ins> docs/man/man1/kubectl-set-serviceaccount.1 </ins> docs/man/man1/kubectl-set-subject.1 docs/man/man1/kubectl-set.1 docs/man/man1/kubectl-stop.1

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST Kubernetes version (use ): HEAD Now that RBAC is going to GA, using ServiceAccounts is getting more and more important. Still a lot of users run their apps/addons/whatever in the SA. In order for the admin to be able to change ServiceAccount easily after an application has been installed (which supposedly is crashlooping due to insufficient privs), a command could exist. I know I can do this: but for new users to Kubernetes, it's non-obvious. Proposed command: Tracking issue: WDYT? This would be a good way for a new contributor to get aquainted with the code by contributing this feature.
Is anyone working on this? If not I would like to take this up.
Nobody is working on this. I would be super happy if you could contribute this feature. Be aware of that there isn't consensus around this proposal yet (I proposed it yesterday, saturday, so people haven't had time to catch up on it) However, I do think that this is in line with , so feel free to start working on this if you want to ;) Also, don't hesitate to ask for help if you don't know how to get started and we'll help out! Thanks!
I'm in favor of this command. ?
Thanks, I will start working on this.
Is the SA on a Pod mutable or immutable? What about DaemonSet and StatefulSet? Do those have SA as well? Is there a way to do this so that it dynamically supports anything with a PodTemplate? Maybe this should be done as a subresource that can be dynamically discovered by kubectl using the discovery service.
Maybe helpful:
Pod is immutable. All the other objects (with the exception of stateful set) are mutable.
That pattern is the same for all the things that set aspects of a pod spec (except image, which is also mutable in pods)
Statefulsets are going to loosen their validation soon I expect.
This sounds good to me. just go ahead, I will help review this. Thanks ~
The outout of this command kubectl get rc/nginx-controller -o=yaml , has service acccount at the following path '' , and the corresponding pod has service account at 'spec.serviceAccountName'.

Both refer to the 'serviceAccountName' field of PodSpec struct but can be made to be different by patching the ReplicationController resource. How does ReplicationController and Pod use serviceAccountName differently? Shouldn't the ReplicationControllerSpec have a serviceAccountName field?
ptal, I think you are more familiar with ReplicationController implementation than me.
ReplicationController contains a pod spec object, which contains a serviceAccountName.
Hi , how to go about writing e2e test cases for this. My development is mostly complete.
I wouldn't mind if you posted the PR now and then we'd see what e2e test makes sense to have. In order to move forward...
what are the next steps?
Change:
highOOMScoreAdj: 3, }, { <del> pod:             &critical, </del> <ins> pod:             &clusterCritical, memoryCapacity:  4000000000, lowOOMScoreAdj:  1000, highOOMScoreAdj: 1000, }, { pod:             &nodeCritical, </ins> memoryCapacity:  4000000000, lowOOMScoreAdj:  -997, highOOMScoreAdj: -997,

Discussion:
<!-- Feature requests are unlikely to make progress as an issue. Instead, please suggest enhancements by engaging with SIGs on slack and mailing lists. A proposal that works through the design along with the implications of the change can be opened as a KEP: --I'd like only pods to have low OOM score -997. introduced a change which ensured all the critical priority classes will have a low OOM score -997. While this helped in relating OOM score to priority of pod, it also allows containers in pods to have -997 OOM score, making them one of the last processes to be OOMKilled. By definition pods can be scheduled elsewhere if there is crunch on the node where as pods cannot be rescheduled. This was the reason for to have higher priority value than . So, I think it makes sense for only pods to have low OOM score of -997. /sig node cc
/triage accepted
i think this is reasonable since is higher priority than and this would make a distinction between the two making killable but assured to be rescheduled
Note that oomscore has nothing to do with rescheduling. Eviction looks at priority, oomscore simply controls the killer. I think that strengthens the argument - the point of node-critical is makinng sure it's killed last, but even then that should be a rare, rare case (a memory leak in kube-proxy will blow out the workload, but if we just killed kube-proxy everything would heal). We may want to go back to the original justifications for -99x oomscore in system-node-critical and make sure we're still aligning correctly.
Change:
// Check all anti-affinity terms. for _, term := range GetPodAntiAffinityTerms(affinity.PodAntiAffinity) { <del> termMatches, _, err := c.anyPodMatchesPodAffinityTerm(pod, filteredPods, node, &term) </del> <ins> termMatches, _, err := c.anyPodMatchesPodAffinityTerm(pod, filteredPods, nodeInfo, &term) </ins> if err != nil || termMatches { glog.V(10).Infof("Cannot schedule pod %+v onto node %v, because of PodAntiAffinityTerm %v, err: %v", podName(pod), node.Name, term, err)

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --It is not a secret that . In my opinion the main reason for the slowness is the flexibility of the inter-pod affinity/anti-affinity rules. However, in most practical scenarios users do not need all the flexibility. For example, people often do not use arbitrary labels in topology key of the affinity rules. They often use node, zone, or region as the topology. Node in particular is used often. That's why I am proposing a fast path for the case that topology key is Node. Today, the affinity/anti-affinity predicate does not have any distinction for topology keys and in the cluster regardless. The logic should recognize "" and scan only pods on the same node for this topology key. Is this a BUG REPORT or FEATURE REQUEST?: FEATURE REQUEST /kind feature /sig scheduling cc/
ref/
/assign
GitHub didn't allow me to assign the following users: misterikkit. Note that only can be assigned. <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
/cc
We found some other simple optimizations that had a significant impact on the affinity predicate. I will upload PRs for those as well.
Reopening this as the performance of anti-affinity still doesn't seem to be satisfactory enough on large clusters (i.e 5k nodes) - and it's causing them to fail to startup. Ref: issue I can help with evaluating any performance improvements if needed.
The change sent improved performance of the predicate, but apparently it is not enough to make our large scale scalability tests happy.
This issue is not about general performance improvment of affinity/anti-affinity. It was to implement a particular improvment which is already implemented. There are other performance improvement issues. I am going to close this one.
Sounds good. Thanks.
How come with kops 1.10.0 I still see all kube-dns pods on the same node because the kube-dns deployment doesn't specify any anti-affinity rule?
I think you are correct. you can double-check with the option to . I have a v1.9 cluster in front of me, and kube-dns has no affinity rules. (I didn't use kops though)
Change:
t.Log(err) } <del> time.Sleep(100 * time.Millisecond) </del> <ins> time.Sleep(time.Second) </ins> } }() <del> if err := wait.PollImmediate(100*time.Millisecond, 10*time.Second, func() (done bool, err error) { </del> <ins> if err := wait.PollImmediate(time.Second, time.Minute, func() (done bool, err error) { </ins> obj := kubeClientConfigValue.Load() if obj == nil { return false, nil } kubeClientConfig := kubeClientConfigValue.Load().(*restclient.Config) <del> kubeClient, err := kclient.NewForConfig(kubeClientConfig) </del> <ins> // make a copy so we can mutate it to set GroupVersion and NegotiatedSerializer cfg := *kubeClientConfig cfg.ContentConfig.GroupVersion = &schema.GroupVersion{} cfg.ContentConfig.NegotiatedSerializer = kapi.Codecs privilegedClient, err := restclient.RESTClientFor(&cfg) </ins> if err != nil { // this happens because we race the API server start t.Log(err) return false, nil } <del> if _, err := kubeClient.Discovery().ServerVersion(); err != nil { </del> <ins> // wait for the server to be healthy result := privilegedClient.Get().AbsPath("/healthz").Do() if errResult := result.Error(); errResult != nil { t.Log(errResult) </ins> return false, nil } <del> return true, nil </del> <ins> var status int result.StatusCode(&status) return status == http.StatusOK, nil </ins> }); err != nil { t.Fatal(err) }

Discussion:
Seeing a variety of failures Address already in use failures https://k8s- Stack traces: https://k8s- https://k8s- Creation errors: https://k8s-
cc
Here's another false negative in TestEtcdStoragePath: https://k8s-
Change:
"io.k8s.api.policy.v1beta1.PodDisruptionBudgetStatus": { "description": "PodDisruptionBudgetStatus represents information about the status of a PodDisruptionBudget. Status may trail the actual state of a system.", "required": [ <del> "disruptedPods", </del> "disruptionsAllowed", "currentHealthy", "desiredHealthy",

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: PodDisruptionBudget provides inappropriate message and cannot be updated as is required filed. What you expected to happen: works fine for editing labels under . Also, produce correct error message when edit field. How to reproduce it (as minimally and precisely as possible): Then, we will get following error after step-2. When edit , it should provide correct message as .When edit especially labels under metadata, they should be updated without error. Anything else we need to know?: According to the code comment, is valid. Environment: Kubernetes version (use ): build on
/sig cli
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 there is a PR open
Change:
return params, nil } <del> func cloneIface(b iscsiDiskMounter, newIface string) error { </del> <ins> func cloneIface(b iscsiDiskMounter) error { </ins> var lastErr error <ins> if b.InitIface == b.Iface { return fmt.Errorf("iscsi: cannot clone iface with same name: %s", b.InitIface) } </ins> // get pre-configured iface records <del> out, err := b.exec.Run("iscsiadm", "-m", "iface", "-I", b.Iface, "-o", "show") </del> <ins> out, err := b.exec.Run("iscsiadm", "-m", "iface", "-I", b.InitIface, "-o", "show") </ins> if err != nil { lastErr = fmt.Errorf("iscsi: failed to show iface records: %s (%v)", string(out), err) return lastErr

Discussion:
What happened: When creating a block volume, the iSCSI storage plugin stores volume-related data in different directories: As a result, some data is not cleaned up once the volume is detached: How to reproduce it (as minimally and precisely as possible): These are the objects I used to reproduce this issue: pod- /sig storage CC
/assign
Change:
cmd/kube-proxy cmd/kubeadm cmd/kubelet <ins> vendor/k8s.io/component-base/logs/kube-log-runner </ins> ) echo "${targets[@]}" }

Discussion:
/kind feature Hey, in K8s 1.23 we are planning to deprecate multiple klog flags. Deprecated flags: , , , , , , , , , , , One of the alpha milestones is requires us to remove usage of deprecated flags within K8s repo. Examples found for windows [ ] [ ] /sig windows /wg structured-logging
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 I've started looking into this. Part of the problem is that go-runner is not part of kubernetes-node-windows- I suspect that is where the scripts get and kube- from.