jiebi/CodeConvo huggingface dataset:
Change:
dc.sync(ctx, pdbName) ps.VerifyDisruptionAllowed(t, pdbName, 0) <del> verifyUnsupportedControllerEventEmitted(t, dc) </del> <ins> verifyEventEmitted(t, dc, "UnmanagedPods") </ins> }

Discussion:
When using PDBs with or (percentage), it is not supported to reference pods via a PDB selector, that do not have a supported controller owner reference: Deployment, ReplicationController, ReplicaSet, and StatefulSet controllers or a resource implementing subresource This is also documented Nevertheless, there are still people who create PDBs a pods without controllers that ignore this. For example PDBs that set , want to block eviction, and node drain (it works for them but the PDB status is invalid). Unfortunately there is no feedback for the user to receive when this happens. The KCM logs is the only place that informs the user when unmanaged pods are found. Which I think is insufficient. There should be some way to inform users about this. Since it cannot be know on admission we probably have to do it when reconciling the PDB and unmanaged pods are found. Options: an event when this is detected - probably needs to be throttled in some way a condition in a PDB status that would be set and admins could monitor these to detect misbehaving PDBs create a PDB create unmanaged pod observe incorrect status because this configuration is unsupported No response <detailsNA </details<detailsNA </details<detailsNA </details<details</details<details</details<details</details
/sig apps
/triage accepted This was discussed during today's sig-apps, we've agreed to add a warning event right next to the log statement from the original description
I'll take this on.
/assign
/reopen I did some more testing for the unsupported controllers and found out that these are covered by the event, so I posted a followup to reflect that The new event should cover only the naked pods
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:
return nil, apierrors.NewBadRequest(fmt.Sprintf("namespace is not allowed on this type: %v", namespace)) } <ins> if len(tokenReview.Spec.Token) == 0 { return nil, apierrors.NewBadRequest(fmt.Sprintf("token is required for TokenReview in authentication")) } </ins> if r.tokenAuthenticator == nil { return tokenReview, nil }

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?: What happened: What you expected to happen: 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
Change:
"github.com/onsi/ginkgo/v2" v1 "k8s.io/api/core/v1" <ins> schedulingv1 "k8s.io/api/scheduling/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/fields" errors "k8s.io/apimachinery/pkg/util/errors" <ins> "k8s.io/apimachinery/pkg/util/uuid" </ins> clientset "k8s.io/client-go/kubernetes" "k8s.io/kubernetes/pkg/kubelet/events" "k8s.io/kubernetes/test/e2e/framework"

Discussion:
For 1.27 we should graduate the ReadWriteOncePod feature to beta. This is needed to rollout the feature to GA. In beta this feature will support preemption of pods using PVCs. See:
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 storage /sig scheduling
Change:
}, "volumeAttributesClassName": { SchemaProps: spec.SchemaProps{ <del> Description: "volumeAttributesClassName may be used to set the VolumeAttributesClass used by this claim. If specified, the CSI driver will create or update the volume with the attributes defined in the corresponding VolumeAttributesClass. This has a different purpose than storageClassName, it can be changed after the claim is created. An empty string value means that no VolumeAttributesClass will be applied to the claim but it's not allowed to reset this field to empty string once it is set. If unspecified and the PersistentVolumeClaim is unbound, the default VolumeAttributesClass will be set by the persistentvolume controller if it exists. If the resource referred to by volumeAttributesClass does not exist, this PersistentVolumeClaim will be set to a Pending state, as reflected by the modifyVolumeStatus field, until such as a resource exists. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#volumeattributesclass (Alpha) Using this field requires the VolumeAttributesClass feature gate to be enabled.", </del> <ins> Description: "volumeAttributesClassName may be used to set the VolumeAttributesClass used by this claim. If specified, the CSI driver will create or update the volume with the attributes defined in the corresponding VolumeAttributesClass. This has a different purpose than storageClassName, it can be changed after the claim is created. An empty string value means that no VolumeAttributesClass will be applied to the claim but it's not allowed to reset this field to empty string once it is set. If unspecified and the PersistentVolumeClaim is unbound, the default VolumeAttributesClass will be set by the persistentvolume controller if it exists. If the resource referred to by volumeAttributesClass does not exist, this PersistentVolumeClaim will be set to a Pending state, as reflected by the modifyVolumeStatus field, until such as a resource exists. More info: https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/ (Alpha) Using this field requires the VolumeAttributesClass feature gate to be enabled.", </ins> Type:        []string{"string"}, Format:      "", },

Discussion:
in link is out of date. the new one is fix link none No response <details</details<detailsnone </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 storage /kind documentation /remove-kind bug
Change:
- name: "coredns-kube-up" <del> version: 1.3.1 </del> <ins> version: 1.6.2 </ins> refPaths: - path: cluster/addons/dns/coredns/coredns.yaml.base match: k8s.gcr.io/coredns

Discussion:
Which jobs are failing: Multiple jobs on . Which test(s) are failing: on the following jobs: Since when has it been failing: Since 5/17. Testgrid links: See above. Reason for failure: All the failures mentioned above seem to have to have the same root cause, namely failure while waiting for CoreDNS to be ready. Example: /sig testing /priority critical-urgent /kind failing test /milestone v1.15 /cc
Some of this (possible all of it) is due to , which is dependent on being merged.
/sig cluster-lifecycle
Not the gce jobs thoght. Only the kinder job. So the gce jobs are failing with a problem outside of kubeadm/kinder but possibly still related to the corefile plugin change
/assign (At kubecon this week)
The gce failures appear to show the same behavior, but with kube-up instead of kubeadm. I.e. it appears that kube-up may also be retaining old configs when upgrading/downgrading. If thats true, then we may need to integrate the migration tools into kube-up as well.
I have opened which aims to fix all the failing tests except , which will be fixed via
Great job so far and Would it be possible to ask for the open PRs to be merged and/or a solution found soon? We have these tests failing for quite some time and code freeze coming up in the next days. Thank you in advance for your efforts!
thanks for the heads up. let me know if you don't have the time for the refactor that i requested and i can try to take over there. the alternative is to rollback the coredns version which i assume is not ideal, due to a variety of fixes in the new version.
is there any more work planned for this issue? I see that some of the kinder jobs are still failing after merged:
merging and will resolve and close this issue.
Thank you for the update !
updates: kinder tests were fixed via
/unassign i was here for: it's a bit flaky (which is due to the tooling), but green.
Since and we're moved to 1.16, and we're waiting for to merge, can we move this issue to 1.16?
? is that the right PR?

Good catch, I meant
The GCE test failures were fixed by and /close
Closing this issue. <detailsIn response to : The GCE test failures were fixed by and /close 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:
if err := opts.Validate(args); err != nil { klog.Fatalf("failed validate: %v", err) } <del> klog.Fatal(opts.Run()) </del> <ins> if err := opts.Run(); err != nil { klog.Exit(err) } </ins> }, }

Discussion:
What happened: logs a nil error on success, EG: . What you expected to happen: kube-proxy shouldn't log an error on success. Either a nil error should be interpreted as success, or an explicit exit boolean should be returned & evaluated. How to reproduce it (as minimally and precisely as possible): Run in master/1.15, or 1.14.2+. Anything else we need to know?: Code indicates that this is a problem ever since exiting was introduced (kube-proxy previously hung). It calls log.Fatal() on the return result, under the now-false assumption that an exit -a crash. Environment: Hyperkube, 1.14.2
/sig network /priority important-longterm /cc
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
GitHub didn't allow me to assign the following users: johscheuer. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I would start looking into this but it seems I can't assign myself
the bot only works on org members
GitHub doesn't allow assigning people unless they are either members of the organization or repo "collaborators". There's no way around this. Kubernetes doesn't use the latter mechanism in favor of the org membership process. (some notes / links in the bot comment). You can certainly take a stab at this without assigning it though
Change:
if err != nil { return nil, err } <ins> if !fwdRuleExists { glog.Infof("Forwarding rule %v for Service %v/%v doesn't exist", loadBalancerName, apiService.Namespace, apiService.Name) } </ins> // Make sure we know which IP address will be used and have properly reserved // it as static before moving forward with the rest of our operations.

Discussion:
Restarting master causes a recreation of fwrule and target pool for type=loadbalancer services. We are saved in the non restart case because we compare a cached verson of the service to decided if we should even call into the cloudprovider and update resources. This is happening because our reconciliation routines are confused about session affintiy and lbip, leading them to recreate, since inplace update isn't allowed. The impact is at best a few seconds of radio silence, at worst who knows? Repro: Create a loadbalanced service, eg: Wait for it to acquire a vip. Try it out Ssh into master and restart kube-controller-manager: Watch the wgets, you'll notice radio silence after a bit. This is because the targetpool and forwarding rule get recreted, for 2 reasons: affinity mismatch So this check fails: Lbip mismatch: So this check fails: (lbip is retrieved here: )
the session affinity fix is trivial. The easiest change for the lb ip fix is to not actually check the ip, but simply backoff as long as the forwarding rule exists. This is "bad" because of the way we allocate a static-ip, assign it to the fwd rule, then de-allocate it. The alternative is to use to reconcile, but that's racy.
cherry pick
Change:
if [[ "${TRAVIS:-}" != "true" ]]; then local go_version go_version=($(go version)) <del> if [[ "${go_version[2]}" < "go1.6" ]]; then </del> <ins> if [[ "${go_version[2]}" < "go1.6" && "${go_version[2]}" != "devel" ]]; then </ins> kube::log::usage_from_stdin <<EOF Detected go version: ${go_version[*]}. Kubernetes requires go version 1.6 or greater.

Discussion:
kubernetes]$ make hack/build- Detected go version: go version devel + Wed Mar 4 20:55:55 2015 +0000 linux/amd64.Kubernetes requires go version 1.2 or greater.Please install Go version 1.2 or later. !!! Error in 'kube::golang::buildbinaries "$ exited with status 2 Call stack: 1: kube::golang::buildbinaries(...) 2: hack/build- main(...) Exiting with status 1 make: * [all] Error 1
Hello, it would be really nice feature to have and it seems easy to fix/implement. Are there any plans on fixing the build?
Change:
scheduledJobTimeout = 5 * time.Minute ) <del> var _ = framework.KubeDescribe("[Feature:ScheduledJob]", func() { </del> <ins> var _ = framework.KubeDescribe("ScheduledJob", func() { </ins> options := framework.FrameworkOptions{ ClientQPS:    20, ClientBurst:  50,

Discussion:
! Please also see /kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --/sig testing
cc
slack thread:
/triage accepted
got one good run!
Change:
Containers: []v1.Container{ { Name:  container1Name, <del> Image: imageutils.GetPauseImageName(), </del> <ins> Image: imageutils.GetE2EImage(imageutils.BusyBox), Command: []string{ "powershell.exe", "-Command", "sleep -Seconds 600", }, </ins> }, { Name:  container2Name, <del> Image: imageutils.GetPauseImageName(), </del> <ins> Image: imageutils.GetE2EImage(imageutils.BusyBox), Command: []string{ "powershell.exe", "-Command", "sleep -Seconds 600", }, </ins> SecurityContext: &v1.SecurityContext{ WindowsOptions: &v1.WindowsSecurityContextOptions{ GMSACredentialSpec: generateDummyCredSpecs(container2Domain),

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI -- [sig-windows] [Feature:Windows] GMSA Kubelet [Slow] kubelet GMSA support when creating a pod with correct GMSA credential specs passes the credential specs down to the Pod's containers [sig-windows] [Feature:Windows] GMSA Full [Serial] [Slow] GMSA support works end to end ** pause image using in image was transitioned to the official pause image which no longer has in the image related to /sig windows /triage accepted
Change:
func (g *GenericPLEG) Healthy() (bool, error) { relistTime := g.getRelistTime() <ins> if relistTime.IsZero() { return false, fmt.Errorf("pleg has yet to be successful") } </ins> elapsed := g.clock.Since(relistTime) if elapsed > relistThreshold { return false, fmt.Errorf("pleg was last seen active %v ago; threshold is %v", elapsed, relistThreshold)

Discussion:
When the kubelet first starts the folllowing error is emitted to the logs This is because the relist has not yet run which results in a duration that is just the time since the zero time instant () xref /sig node
/assign
/approve /lgtm
help if i approve the pr and not the issue ;-)
Change:
count += int(event.Count) } if count != num { <del> return fmt.Errorf("expect event number %d, got %d: %v", num, count, events.Items) </del> <ins> return fmt.Errorf("expected total number of events was %d, actual events counted was %dnEvents  : %v", num, count, events.Items) </ins> } return nil }

Discussion:
The NodeProblemDetector test - SystemLogMonitor should generate node condition and events for corresponding errors can produce the following error message which is misleading This message outputted by verifyTotalEvents is meant to indicate that a specific number of occurrences of events is expected but an unexpected number of events occurred during the test run. It's misleading because it can be interpreted as where 7 and 4 are event IDs instead of event counts Example
I have implemented a fix for this and will submit the PR soon /sig node
Change:
"github.com/onsi/gomega" ) <del> var _ = framework.KubeDescribe("NodeProblemDetector [NodeFeature:NodeProblemDetector]", func() { </del> <ins> var _ = framework.KubeDescribe("NodeProblemDetector [NodeFeature:NodeProblemDetector] [Serial]", func() { </ins> const ( pollInterval   = 1 * time.Second pollConsistent = 5 * time.Second

Discussion:
Is this a valid test? My understanding is we cannot rely on events for programming against. Which jobs are flaking: ci-cri-containerd-node-e2e-features ci-kubernetes-node-kubelet-features among others, mainly 'node-e2e-features' based tests. Which test(s) are flaking: Testgrid link: Reason for failure: expected total number of events was 4, actual events counted was 7 Anything else we need to know: It doesn't fail in a specific environment, should this test be running at all outside of this job? The comments inside the test aren't very helpful for understanding why we're checking what we're checking.
I heard this is blocking you. /sig node /cc
I see flakes going back at least a month In addition to an earlier issue clarifying the error message This might be a spurious match,
NodeProblemDetector is broken on nearly every run:
Maybe they should be marked [serial] or [disruptive]?
We can mark it and move it to the flake job, but I fear it will work fine over there.
Edit in upstream issue says "needs to be marked serial" I'll make a PR
Change:
runtimeapi "k8s.io/kubernetes/pkg/kubelet/apis/cri/runtime/v1alpha2" "k8s.io/kubernetes/pkg/kubelet/apis/kubeletconfig" "k8s.io/kubernetes/pkg/kubelet/checkpointmanager" <ins> "k8s.io/kubernetes/pkg/kubelet/checkpointmanager/errors" </ins> kubecontainer "k8s.io/kubernetes/pkg/kubelet/container" "k8s.io/kubernetes/pkg/kubelet/dockershim/cm" "k8s.io/kubernetes/pkg/kubelet/dockershim/network"

Discussion:
/kind bug are failing. seems like the likely cause. cc /assign
ping
seems one test still failing.
Change:
for _, item := range table { result, err := aws.List(item.input) if err != nil { <del> t.Errorf("Expected call with %v to succeed, failed with %s", item.input, err) </del> <ins> t.Errorf("Expected call with %v to succeed, failed with %v", item.input, err) </ins> } if e, a := item.expect, result; !reflect.DeepEqual(e, a) { t.Errorf("Expected %v, got %v", e, a)

Discussion:
sig-release-1.27-informing capz-windows-containerd-1.27 04-05 23:42 IST https://k8s- No response /sig node
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
Is is related to
Yes it is related. The images published to the repository do not have entries for Windows Server 2022 containers so this test will fail test passes that use Windows Server 2022 for all the Windows nodes.
I will either skip the test for this test pass or update the image REPO_LIST used by this test to point to a different container registry that has a valid image for this test.
Change:
mux.Handle(prefix+"/redirect/", http.StripPrefix(prefix+"/redirect/", redirectHandler)) mux.Handle(prefix+"/operations", http.StripPrefix(prefix+"/operations", opHandler)) mux.Handle(prefix+"/operations/", http.StripPrefix(prefix+"/operations/", opHandler)) <ins> if validator != nil { mux.Handle(prefix+"/validate", validator) } </ins> } }

Discussion:
If the scheduler is not healthy, pods won't schedule and things will get stuck in pending. Right now, there is no user visible feedback (in logs or events or pod status) that indicates that this is true. We should really have at least some logging in the apiserver, and possibly more in-depth information. I'm thinking that we should add a /validatez handler to the apiserver that does a quick sanity check. Added bonus: we could rip out all of the scripted health checking in the startup scripts.
A simple status HTTP page would be useful, showing the health status of each system component. We should seriously think about self-hosting, too. It doesn't seem like it would be hard to run a couple scheduler replicas using master election, managed by a replication controller.
Yeah, I think system components should register themselves with apiserver.
Change:
MounttestUser            = ImageConfig{e2eRegistry, "mounttest-user", "1.0"} Nautilus                 = ImageConfig{e2eRegistry, "nautilus", "1.0"} Net                      = ImageConfig{e2eRegistry, "net", "1.0"} <del> Netexec                  = ImageConfig{e2eRegistry, "netexec", "1.0"} </del> <ins> Netexec                  = ImageConfig{e2eRegistry, "netexec", "1.1"} </ins> Nettest                  = ImageConfig{e2eRegistry, "nettest", "1.0"} Nginx                    = ImageConfig{dockerLibraryRegistry, "nginx", "1.14-alpine"} NginxNew                 = ImageConfig{dockerLibraryRegistry, "nginx", "1.15-alpine"}

Discussion:
/kind bug /sig release when we use , we must make sure xxx is not nil. So before we use it, we should check err value first. Such as:
I think even if the file is nil , maybe It doesn't matter
Sometimes it does matter, while can't handle nil correctly. Maybe it is just a good practise.
Although File.Close() can handle cases like this, serverConn.Close() will cause panic to happen. Anyway, these are bugs that exist. /assign