jiebi/CodeConvo huggingface dataset:
Change:
for i := range podList.Items { p := podList.Items[i] <del> if podutil.IsPodReady(&p) { </del> <ins> if podutil.IsPodReady(&p) && p.ObjectMeta.DeletionTimestamp.IsZero() { </ins> pod = &p return true, nil }

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 --Which jobs are flaking: all of the e2e jobs that run this test Which test(s) are flaking: ` Testgrid link: Reason for failure: mostly: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated /sig apps xref:
approx:
my suspicion: /
I can't find anything else that seems relevant in the time frame, and it is the only change to the test file in that time frame.
merged recently, not sure if it's relevant
Not sure what the procedure it, but we can revert or try some other image instead of Pause, if you think it helps. I don't have a good explanation why the change would make the test flake like this.
I don't have a good explanation, just that it affects the test and is in the time frame that seems to fit the flake spike It may take a bit to pin down what exactly happened here :/ I can't look for a little bit.
I tried to reproduce this behaviour on a test cluster in AWS, but couldn't. I prepared a PR to revert the change, just incase.
Good news and bad news kind of thing... The same test fails in the revert PR also, with the previous EchoServer image:
I did an experiment reverting the second suspect in I couldn't reproduce the issue anymore even though I tried. You can check the results in the PR history.
I believe I have found the issue here. More information and fix incoming
Thanks for the update
I just about have a fix ready here. I was able to narrow the commit range to by looking at when this flake first occurred in It looks like was correct that this was introduced in . I believe what is happening is that in the test we are getting getting a with a set (the one that we previously successfully issued an eviction for) before waiting for 3 pods to be ready again in the namespace (). Before the aforementioned PR caused us to skip checking PDBs when is set we would still report back that eviction was not possible because our with did not meet the other criteria (i.e.

was not , , or ), which caused us to still check PDBs, which would show us that we did not have the budget to delete (even though it was not really taking into account the that we were actually attempting to evict). I think there are a few things we can do to address this: we should check that not only is the , but also that it does not have set. above where we call so that we do not attempt to get a before all of the pods are ready. in that the does not have a . Just doing (3) by itself would address our current problem, but (1) and (2) also seem to make sense in the context of what we are trying to check here.
Thanks everyone and apologies for the false alarm :-)
/lifecycle active /priority critical-urgent (this is blocking merges of other fixes) /assign
/milestone v1.19
Change:
var pod, pod1, pod2 *v1.Pod It("should assign CPUs as expected based on the Pod spec", func() { <del> oldCfg = enableCPUManagerInKubelet(f) </del> cpuCap, cpuAlloc, cpuRes = getLocalNodeCPUDetails(f) <del> // Skip CPU Manager tests if the number of allocatable CPUs < 1. if cpuAlloc < 1 { framework.Skipf("Skipping CPU Manager tests since the number of allocatable CPUs < 1") </del> <ins> // Skip CPU Manager tests altogether if the CPU capacity < 2. if cpuCap < 2 { framework.Skipf("Skipping CPU Manager tests since the CPU capacity < 2") </ins> } <ins> // Enable CPU Manager in the kubelet. oldCfg = enableCPUManagerInKubelet(f) </ins> By("running a non-Gu pod") ctnAttrs = []ctnAttribute{ {

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Test failed when running CPU Manager node e2e test on Ubuntu 16.04 locally, and show this panic message: What you expected to happen: Tests passed. How to reproduce it (as minimally and precisely as possible): Run this node e2e test, use the following command: Anything else we need to know?: I think this is because the following codes: is . I will send a PR to fix this after it is confirmed. /sig node /assign PTAL, Thanks!
Thanks for the bug report. Reproduced successfully. It looks like the response body may have changed from empty map to null, which caused this to break. In any case, suggested adding the fix to his pending PR here:
Hi, have fixed this, lgtm.
Change:
} for _, test := range tests { <del> authenticator := bearertoken.New(bootstrap.NewTokenAuthenticator(bootstrapSecrets{test.secret})) </del> <ins> authenticator := group.NewAuthenticatedGroupAdder(bearertoken.New(bootstrap.NewTokenAuthenticator(bootstrapSecrets{test.secret}))) </ins> // Set up an API server controlPlaneConfig := framework.NewIntegrationTestControlPlaneConfig() controlPlaneConfig.GenericConfig.Authentication.Authenticator = authenticator

Discussion:
While moving APF to beta (see comments on ), we discovered that the integration tests commonly present users which are not members of any groups. We had thought that the system enforced membership in either the authenticated or unauthenticated group. If this is supposed to be a system invariant (as we thought), we'd like to ask SIG Auth: Please fix the integration tests Please add e.g. logging so that if real, operational clusters hit this there's at least a log message and people will file bugs. /sig auth
Can I suggest also, if this is a real invariant, that it be documented in some place(s) likely to be read?
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
/remove-lifecycle stale /priority important-longterm /triage accepted
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]:
/lifecycle frozen
fixes the authenticator configured in one of the integration test API server startup helpers which resolved this issue for . Remaining tests that still need fixing that are encountering unexpected users look to be ones set up to specifically test auth paths:
open to fix remaining integration test users
Change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/schema" <ins> "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/uuid" </ins> admissionapi "k8s.io/pod-security-admission/admission/api" "k8s.io/pod-security-admission/api" "k8s.io/pod-security-admission/metrics"

Discussion:
When updating policy labels on a namespace, existing pods are evaluated to see if they are compatible with the new policy. If there are too many pods, or if evaluation takes too long, we short circuit and warn that not all pods were checked. For that reason, we want to prioritize checking a variety of pods before checking essentially identical pods, so that unique warnings can be surfaced before reaching the pod count cutoff or evaluation timeout. Pods created by the same controller are most likely to be identical (e.g. replicas from a replicaset or job, copies of pods from a statefulset or daemonset, etc) cc
This is an interesting fix I'd like to take this up Can I take this up? I am fairly new to Kubernetes source code so might need some help
I am guessing this is where the logic you mentioned should be implemented right?
thanks for the interest; this is targeted at the beta version... right now, effort is going toward the alpha-blocking work for 1.22
Should I wait for the code freeze before working on this? Sorry for lame questions
If you want to start looking at it, that's fine, but it's possible the code in the ValidateNamespace function will change before we're ready to start merging 1.23 work, and there isn't really reviewer bandwidth to take a look at work-in-progress stuff for next release yet.
Sure, I'll just for code freeze before I start with implementation By the time I'll just assign this to myself /assign
Does it make sense to take it up now? I think we already have a couple of RC builds after the code freeze
sure, it's fine to start work in a branch in your fork and have a WIP PR open, even before master reopens for 1.23 work
Awesome, I'll start working on it Thank you
Hello! Are you still working on this? If you don't have time, I can take this issue. If not, maybe I can give some help
Since this was not an urgent issue I was working on some other issues last week I have started on this, Will be raising a PR maybe today or tomorrow I Will ask you if I get stuck Thank you
Change:
// ResourceList is a set of (resource name, quantity) pairs. type ResourceList map[ResourceName]resource.Quantity <del> // Get is a convenience function, which returns a 0 quantity if the // resource list is nil, empty, or lacks a value for the requested resource. // Treat as read only! func (rl ResourceList) Get(name ResourceName) *resource.Quantity { if rl == nil { return &resource.Quantity{} } q := rl[name] return &q } </del> // Node is a worker node in Kubernetenes // The name of the node according to etcd is in ObjectMeta.Name. type Node struct {

Discussion:
No other types have helper methods, and this does weird things with pointers.
It's a clean build/test without that helper method. See .
Change:
images []container.Image } <del> // set updates image cache. </del> <ins> // set sorts the input list and updates image cache. // 'i' takes ownership of the list, you should not reference the list again // after calling this function. </ins> func (i *imageCache) set(images []container.Image) { i.Lock() defer i.Unlock() <ins> // The image list needs to be sorted when it gets read and used in // setNodeStatusImages. We sort the list on write instead of on read, // because the image cache is more often read than written sort.Sort(sliceutils.ByImageSize(images)) </ins> i.images = images } <del> // get gets a sorted (by image size) image list from image cache. // There is a potentical data race in this function. See PR #60448 // Because there is deepcopy function available currently, move sort // function inside this function </del> <ins> // get gets image list from image cache. // NOTE: The caller of get() should not do mutating operations on the // returned list that could cause data race against other readers (e.g. // in-place sorting the returned list) </ins> func (i *imageCache) get() []container.Image { i.Lock() defer i.Unlock() <del> sort.Sort(sliceutils.ByImageSize(i.images)) </del> return i.images }

Discussion:
See Today kubelet image manager returns the internal image list cache to caller directly. However, in we sort the image list, which introduces a data race. We should let image manager return a copy of image list instead of returning the list directly. /cc
There are no sig labels on this issue. Please add a sig label. <detailsA sig label can be by either: 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. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals 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
Code Freeze for 1.10 begins in 2 hours. If this issue represents a bug or change for 1.10, then it needs SIG approval in the form of a status/approved-for-milestone label. It also needs a priority/ Thanks!
Change:
// serialTestsRegexp is the default skip value if running in parallel. Will not // override an explicit E2E_SKIP value. <del> serialTestsRegexp = "[Serial]" </del> <ins> serialTestsRegexp = "[Serial]" </ins> )

Discussion:
What happened: When using sonobuoy to run some community tests, I realized that ginkgo was not invoked properly. More precisely, when invoking sonobuoy like this: I saw the following in the sonobuoy logs: Because I am running the tests in parallel, and sonobuoy does not set , the code defaults to (see ) for , and is set to . This is not the intended regex (should be ) and all the tests are skipped (because all test names have an ). What you expected to happen: should be set to so that only the tests with the "tag" are skipped. How to reproduce it (as minimally and precisely as possible): Use the sonobuoy command provided above. Environment:
I opened a PR for this
/sig testing
Change:
lb := NewLoadBalancerRR() lb.OnUpdate([]api.Endpoints{{JSONBase: api.JSONBase{ID: "echo"}, Endpoints: []string{net.JoinHostPort("127.0.0.1", port)}}}) <del> p := NewProxier(lb) </del> <ins> p := NewProxier(lb, "127.0.0.1") </ins> proxyPort, err := p.addServiceOnUnusedPort("echo") if err != nil {

Discussion:
kube-proxy listens on all ports, but should be configurable. create a flag to specify which interface to listen on. Thanks for finding this bug.
For context, some providers apparently do external IPs by having a whole interface that gets 1:1 NAT without any firewalling. We do not want service ports on those interfaces. , Brian Ketelsen wrote:
Change:
dockertypes "github.com/docker/docker/api/types" "k8s.io/klog/v2" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2" kubeletconfig "k8s.io/kubernetes/pkg/kubelet/apis/config" "k8s.io/kubernetes/pkg/kubelet/checkpointmanager"

Discussion:
What happened: Windows kubelet panic occasionally on nodes which have high volume of pods run and delete. Full logs: Preliminary investigate result: How to reproduce it (as minimally and precisely as possible): Run high volume of pods and delete them when they completed in Windows nodes. Environment: Kubernetes version (use ): 1.17.7 Cloud provider or hardware configuration: Azure AKS OS (e.g: ): Windows Server 2019 Kernel (e.g. ): 10.0..1282
/assign I would like to give this a shot.
/remove-sig windows I think this is not a windows specific problem. /sig node /area kubelet
Hi! Thanks for your report, I have filed to address this issue.
This issue is a bit urgent for our situation, it occurs every few days in production clusters. Seems the PR is pending a few days, is it possible to increase the priority to merge it trunk and 1.17/1.18 branch? Thanks
I understand how urgent this issue is, but I am not privileged to do anything further :(
Do you know anyone who can help?
looks like a simple fix, add a lock for , I could help.
There is already a fix by , the problem is the PR is pending, not sure if you or someone can increase the priority to merge it trunk and 1.17/1.18 branch asap. Our AKS clusters are affecting by this frequently.
Thanks guys.
Change:
"//cmd/kube-proxy/app/options:go_default_library", "//cmd/kubelet/app:go_default_library", "//pkg/api:go_default_library", <ins> "//pkg/api/v1:go_default_library", </ins> "//pkg/apis/componentconfig:go_default_library", "//pkg/apis/componentconfig/v1alpha1:go_default_library", "//pkg/client/clientset_generated/clientset:go_default_library",

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): bug Kubernetes version (use ): master Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: When testing , I found kube-proxy can not record event with following errors. What you expected to happen: No errors How to reproduce it (as minimally and precisely as possible): cc
I am still getting this with the latest build
, thanks for your feedback, I'll check it.
Change:
var _ volume.VolumePlugin = &gitRepoPlugin{} <del> var wrappedVolumeSpec = volume.Spec{ Volume: &api.Volume{VolumeSource: api.VolumeSource{EmptyDir: &api.EmptyDirVolumeSource{}}}, </del> <ins> func wrappedVolumeSpec() volume.Spec { return volume.Spec{ Volume: &api.Volume{VolumeSource: api.VolumeSource{EmptyDir: &api.EmptyDirVolumeSource{}}}, } </ins> } const (

Discussion:
Data as of June 3rd, 9:00 PM Eastern. Latest data can be found here: Prow link to the 2 jobs: * Additional Context:
/sig storage cc
I'm working on , it's hard to get a job yaml right at the first time. I'll check iscsi. /assign
/triage accepted /kind failing-test
ci-kubernetes-e2e-storage-kind-disruptive fixed: has 1 green run pull-kubernetes-e2e-storage-kind-disruptive fixed: , it fails when it should fail, it's green otherwise, I'll continue with iscsi.
/reopen it's still red, but at least it installs now:
Reopened this issue. <detailsIn response to : /reopen it's still red, but at least it installs now: 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
e2e-gce-iscsi-serial job passes now: e2e-gce-iscsi is getting greener: I'll let it run for few more days to see if today's failures are flakes. /reopen
Reopened this issue. <detailsIn response to : It's getting greener: /reopen </details
iscsi-serial is green:
Change:
"bytes" "errors" "fmt" <ins> "io/ioutil" </ins> "net" <ins> "os" "path/filepath" </ins> "sort" "testing"

Discussion:
Currently, kubelet mounts hosts file for pods. For hostNetwork pods, the behavior is different and instead, kubelet relies on docker (or whatever container runtime) to mount the host's hosts file. We should have kubelet handle hosts file for hostNetwork pods. This would have several benefits: control over hosts file in case the container runtime does something consistent behavior between hostNetwork and non-hostNetwork pods consistent behavior between different container runtimes -managed hosts file enables features like to be used for hostNetwork pods Implementation would require: kubelet's or its caller output different content based on hostNetwork. i. If it's not hostNetwork, use existing behavior. ii. If it's using hostNetwork, read the content from the host's hosts file. hostNetwork constraint in deciding whether to mount the file Open Questions: do we treat changes to the host's hosts file? should the file's content be static between container restarts of the same Pod? or should every container restart pick up the latest content of the hosts file? the former seems better for consistency, but letter might be more in line with other features that use host resources like host volumes. condition to manage hosts file also excludes windows even though windows also the use of hosts file and the same format. seems like this should be supported also. windows-support ships, should it have validation against windows platform? the tricky bit is the client, API, and minions' kubelet may be running on different platforms, and currently, there's no precedence to platform validation. /kind feature /sig node
Change:
config      *PerTestConfig testCleanup func() <del> cs     clientset.Interface ns     *v1.Namespace sc     *storagev1.StorageClass pvc    *v1.PersistentVolumeClaim pv     *v1.PersistentVolume volume TestVolume </del> <ins> cs clientset.Interface ns *v1.Namespace // genericVolumeTestResource contains pv, pvc, sc, etc., owns cleaning that up genericVolumeTestResource </ins> } var ( dInfo = driver.GetDriverInfo()

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 Which test(s) are failing: I0221 20:48:18.462] [sig-storage] In-tree Volumes I0221 20:48:18.462] [[0m I0221 20:48:18.462] [Driver: gcepd] I0221 20:48:18.462] [[0m I0221 20:48:18.462] [Testpattern: Dynamic PV (filesystem volmode)] volumeMode I0221 20:48:18.463] [[0m I0221 20:48:18.463] should create sc, pod, pv, and pvc, read/write to the pv, and delete all created resources Since when has it been failing: unsure Testgrid link: Reason for failure: From the logs, it looks like it's deleting both PVC and PV objects at the same time, which is not correct. I0221 20:48:18.460] Feb 21 20:48:09.866: INFO: Deleting PersistentVolumeClaim "pvc-cjv2l" I0221 20:48:18.460] Feb 21 20:48:09.923: INFO: Deleting PersistentVolume "pvc--3619-11e9-b923-" should be changed to only delete PVC and wait for PV to be deleted by the driver. Can it just call which does it correctly? Anything else we need to know:
cc
It has been like that already before my recent code refactoring: Therefore I have to defer to - I myself don't really know what this test does or why it was written like that.
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect
/priority critical-urgent
Change:
// AddService starts listening for a new service on a given port. func (proxier Proxier) AddService(service string, port int) error { // Make sure we can start listening on the port before saying all's well. <del> ln, err := net.Listen("tcp", fmt.Sprintf(":%d", port)) </del> <ins> l, err := net.Listen("tcp", fmt.Sprintf(":%d", port)) </ins> if err != nil { return err } <del> log.Printf("Listening for %s on %d", service, port) // If that succeeds, start the accepting loop. go proxier.AcceptHandler(service, ln) </del> <ins> proxier.addServiceCommon(service, l) </ins> return nil } <ins> // addService starts listening for a new service, returning the port it's using. // For testing on a system with unknown ports used. func (proxier Proxier) addServiceOnUnusedPort(service string) (string, error) { // Make sure we can start listening on the port before saying all's well. l, err := net.Listen("tcp", ":") if err != nil { return "", err } proxier.addServiceCommon(service, l) _, port, err := net.SplitHostPort(l.Addr().String()) return port, nil } func (proxier Proxier) addServiceCommon(service string, l net.Listener) { log.Printf("Listening for %s on %s", service, l.Addr().String()) // If that succeeds, start the accepting loop. go proxier.AcceptHandler(service, l) } </ins> func (proxier Proxier) OnUpdate(services []api.Service) { log.Printf("Received update notice: %+v", services) for _, service := range services {

Discussion:
On GCE, if you create a cluster with a name like , then KCM will fail to create the routes, because it includes the cluster name in the route name, but does not escape it to meet GCE requirements. See The following error is logged (lightly edited): Possible solutions: In kops I have built an escaping that is URL inspired, but instead of %2F I use -2F We could just replace every invalid character with a dash or simply omit it. We truncate this anyway, so we do expect collisions at this level (the nameHint is the node UUID and gives us uniqueness)
/sig cluster-lifecycle /area platform/gce since we lack a sig-gcp at the moment
This relates to
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
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