jiebi/CodeConvo huggingface dataset:
Change:
"k8s.io/kubernetes/pkg/api/v1" "k8s.io/kubernetes/pkg/apimachinery/registered" "k8s.io/kubernetes/pkg/apis/apps" <ins> "k8s.io/kubernetes/pkg/apis/batch" </ins> "k8s.io/kubernetes/pkg/apis/extensions" clientset "k8s.io/kubernetes/pkg/client/clientset_generated/internalclientset" "k8s.io/kubernetes/pkg/client/clientset_generated/release_1_5"

Discussion:
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite} Happened on a presubmit run in . Previous issues for this test:
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
Change:
if err := wait.PollUntilContextTimeout(ctx, waitInterval, timeout, true, func(ctx context.Context) (bool, error) { updatedJob, err := clientSet.BatchV1().Jobs(jobObj.Namespace).Get(ctx, jobObj.Name, metav1.GetOptions{}) if err != nil { <del> t.Fatalf("Failed to get updated Job: %v", err) </del> <ins> t.Logf("Failed to get updated Job: %v", err) return false, nil </ins> } actualCounts = podsByStatus{ Active:      int(updatedJob.Status.Active),

Discussion:
pull-kubernetes-integration TestSuccessPolicy/jobwithsuccessPolicywithsucceededCount;jobhasSuccessCriteriaMetandCompleteconditionsevenifsomeindexesremainpending 2024-09-27 No response /sig apps
/assign
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Thank you for letting me know. I will try to investigate the root cause of the flaky case.
It seems that this failure is not related to the test case. It looks like test infrastructure limitations. What do you think?
Maybe it's a sign that we are putting too short of a deadline somewhere?
I think so too. Actually, we can see the same error in as well. So I would propose increasing timeout here: WDYT?
I don't think that would help:
That makes sense. In that case, can we output the log and retry the listing instead of disrupting polling there?
The root cause is disrupting the polling if the listing fails even once.
My proposal is the following:
I see, yeah. But I wonder if the passed to contains any additional timeout. Maybe not.
It seems that we received dedicated timeout as a last arg and then set the timeout to like this: So, I think that it looks better to retry the listing until reaching the polling deadline.
Throughout more investigation, it seems that the returns err immediately once the condition func returns err there:
I simulated the error situation in my local like this:
I opened the PR, PTAL:
Change:
return KeyError{item, err} } keys.Insert(key) <del> if err := f.queueActionLocked(action, item); err != nil { </del> <ins> if err := f.queueActionInternalLocked(action, Replaced, item); err != nil { </ins> return fmt.Errorf("couldn't enqueue object: %v", err) } }

Discussion:
We use a to nil out the : However on a re-sync, this results in a data race that was observed when running unit tests: The read had occurred previously during a callback. On re-sync, the retrieves every object from the cache, invokes the transform function, and re-queues them. However, the object instances are the same as those stored in the cache so mutating them outside the cache without lock protection is unsafe. It is documented that the "TransformFunc sees the object before any other actor, and it is now safe to mutate the object in place instead of making a copy" however this is not the case on a re-sync. The should make a copy of the objects retrieved from the cache store on a re-sync or perhaps elide the on a re-sync since the objects would already have been transformed. As a workaround, I changed our to only nil the if not already nil but this is a latent bug that others will likely run into.
/assign That means that and introduced possible panic regressions into kube-controller-manager and kube-scheduler /priority critical-urgent /kind regression
/transfer kubernetes
/sig api-machinery
kube-controller-manager and kube-scheduler do the same in 1.29+ and likely have the same issue
I think delete has the same problem, and replace may have the same problem: Passing the same object to the transformer after it is already in the cache is unsafe and we should not do that at all.
/assign /cc
Looking into this. I may take time to come up with a proper fix. But would like to evaluate the risk for the current situation. Not entirely sure how delete and replace would be triggered in normal settings, but resync is fortunately low frequency as the default setting for resync period is between 12h and 24h for (--min-resync-period duration Default: 12h0m0s, see ) . As for the resync function is Just think out aloud, I read a thread discussion somewhere that resync was a mechanism in the past to prevent data inconsistency due to bugs but client-go has been mature these days, resync is no-longer needed in theory but for a safe guard. So maybe disabling resync is a reasonable fix if delete/replace can be fixed.
You're mixing resync with relist - I believe relist is no longer needed. Resync is actually used.

FWIW - I opened an initial version of the fix:
I think it's resync. The thread I mentioned is
/triage accepted
Change:
return true, nil } <del> if len(limitRanges.Items) > 0 { if limitRanges.Items[0].ObjectMeta.DeletionTimestamp == nil { framework.Logf("deletion has not yet been observed") return false, nil } return true, nil </del> <ins> for i := range limitRanges.Items { lr := limitRanges.Items[i] framework.Logf("LimitRange %v/%v has not yet been deleted", lr.Namespace, lr.Name) </ins> } return false, nil <del> })) framework.ExpectNoError(err, "kubelet never observed the termination notice") </del> <ins> }) framework.ExpectNoError(err) </ins> ginkgo.By("Creating a Pod with more than former max resources") pod = newTestPod(podName+"2", getResourceList("600m", "600Mi", "600Gi"), v1.ResourceList{})

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: Which test(s) are flaking: Testgrid link: Reason for failure: Anything else we need to know: /sig scheduling /priority critical-urgent /cc /milestone v1.19 This test waits for the limit range to be deleted before attempting to create the so this error is surprising. It appears there are no limit ranges present when they are listed here:
It seems this job failed just once since Jul 23, so I'm wondering is it a must for 1.19?
Given this is a conformance test I would prefer we at least know what is causing the issue
This is still flaking with this same issue. /reopen
Reopened this issue. <detailsIn response to : This is still flaking with this same 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
/milestone v1.20
This issue has not occurred recently and seems to have already been fixed. I think we can close this issue.
Yes, was expected to get it fixed. /close
Closing this issue. <detailsIn response to : Yes, was expected to get it fixed. 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
this is still flaking in the 1.20 branch : confused : as of one hour ago
Change:
disk, rerr := c.common.cloud.DisksClient.Get(ctx, resourceGroup, diskName) if rerr != nil { <ins> if rerr.HTTPStatusCode == http.StatusNotFound { klog.V(2).Infof("azureDisk - disk(%s) is already deleted", diskURI) return nil } </ins> return rerr.Error() }

Discussion:
The fix from seems to be incomplete/wrong. When disk is not found, the GET call for the disk fails with and it is not even reaching the DELETE call. PV to be deleted (its finalizer to be removed) when the underlying disk is already gone. a PVC. the created Azure disk and delete it manually. , delete the PVC. sure that corresponding PV fails to be deleted with reason: No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig cloud-provider /sig storage /area provider/azure /cc
this issue was fixed in CSI driver: what k8s version are you using now?
19.15 PS: This detail is provided in the issue itself. :)
should fix this issue, once it's merged into master branch, I will cherry pick to 1.23, 1.22, 1.21, and for the other versions, I think you need to patch with this PR by yourself, thanks.
/triage accepted /assign
Change:
return claim }(), }, <ins> "good-parameters-apigroup": { claim: func() *resource.ResourceClaim { claim := testClaim(goodName, goodNS, goodClaimSpec) claim.Spec.ParametersRef = &resource.ResourceClaimParametersReference{ APIGroup: goodAPIGroup, Kind:     "foo", Name:     "bar", } return claim }(), }, "bad-parameters-apigroup": { wantFailures: field.ErrorList{field.Invalid(field.NewPath("spec", "parametersRef", "apiGroup"), badAPIGroup, "a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')")}, claim: func() *resource.ResourceClaim { claim := testClaim(goodName, goodNS, goodClaimSpec) claim.Spec.ParametersRef = &resource.ResourceClaimParametersReference{ APIGroup: badAPIGroup, Kind:     "foo", Name:     "bar", } return claim }(), }, </ins> "missing-parameters-kind": { wantFailures: field.ErrorList{field.Required(field.NewPath("spec", "parametersRef", "kind"), "")}, claim: func() *resource.ResourceClaim {

Discussion:
Following YAML file is accepted without error. Notice the field, it is an instead of , containing character. This can lead to an issue when resource driver generates structured parameters' in-tree object with being just without version. The DRA scheduler plugin will try to match the parameters object based on the reference here: In latest master the code appears to use an indexer, and the issue might be hidden, if applicable at all. I did not check the reproducibility in master yet. However, main question is whether the should allow value with character in general. An error is expected from the apiserver upon object creation request, reporting that APIGroup containes APIVersion. Maybe. Have any resource driver that supports structured parameters, , for instance, also puts (gpucrd.APIGroup) value into . v1.30.1 <details</details<details</details<details</details<details</details<detailsscheduler's dynamicresources plugin </details
/sig node /triage accepted
/assign
Change:
<ins> load("@io_bazel_rules_go//go:def.bzl", "go_test") go_test( name = "go_default_test", srcs = ["compatibility_test.go"], deps = [ "//pkg/apis/core/install:go_default_library", "//pkg/scheduler/algorithmprovider/defaults:go_default_library", "//pkg/scheduler/api:go_default_library", "//pkg/scheduler/api/latest:go_default_library", "//pkg/scheduler/factory:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime/schema:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", "//staging/src/k8s.io/client-go/informers:go_default_library", "//staging/src/k8s.io/client-go/kubernetes:go_default_library", "//staging/src/k8s.io/client-go/rest:go_default_library", "//staging/src/k8s.io/client-go/util/testing:go_default_library", ], ) filegroup( name = "package-srcs", srcs = glob(["**"]), tags = ["automanaged"], visibility = ["//visibility:private"], ) filegroup( name = "all-srcs", srcs = [":package-srcs"], tags = ["automanaged"], visibility = ["//visibility:public"], ) </ins>

Discussion:
PLEASE COORDINATE WITH SIG-SCHEDULING BEFORE WORKING ON THIS ISSUE. We want to avoid the situation where two people accidentally start work on the same fix. Main tracking issue: If you contributed in phase 1, please give others a chance before claiming this issue. You can also help out by reviewing the phase 2 PRs. The tests in ensure backwards compatibility with the types in . It makes more sense for these tests to live in that package. /sig scheduling /kind cleanup /help /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 : PLEASE COORDINATE WITH SIG-SCHEDULING BEFORE WORKING ON THIS ISSUE. We want to avoid the situation where two people accidentally start work on the same fix. The tests in ensure backwards compatibility with the types in . It makes more sense for these tests to live in that package. /kind cleanup /help /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
I would like to take it and thanks
Hi! I am contributer and I would like to take it.
while you're working on do you mind letting take a crack at this one?
OK, go head
, thanks!
/lifecycle active for
Thanks for taking care of this one! :smiley:
You are wellcome
Change:
"List of allowed origins for CORS, comma separated.  An allowed origin can be a regular "+ "expression to support subdomain matching. If this list is empty CORS will not be enabled.") <ins> fs.StringSliceVar(&s.HSTSDirectives, "strict-transport-security-directives", s.HSTSDirectives, ""+ "List of directives for HSTS, comma separated. If this list is empty, then HSTS directives will not "+ "be added. Example: 'max-age=31536000,includeSubDomains,preload'") </ins> deprecatedTargetRAMMB := 0 fs.IntVar(&deprecatedTargetRAMMB, "target-ram-mb", deprecatedTargetRAMMB, "DEPRECATED: Memory limit for apiserver in MB (used to configure sizes of caches, etc.)")

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add the "Strict-Transport-Security" header to the API server responses. Why is this needed: Nessus scanner treats this as a Medium Risk in kubernetes 1.18.10.
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 api-machinery
/remove-sig api-machinery /sig auth
Change:
forwardedURI string redirect     string redirectWant string <ins> reqHost      string </ins> } table := map[string]Item{

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: When accessing a service (e.g., ) by using the Apiserver proxy feature and the service returns with header, such as The returned header does not preserve the path if the service sent a redirect with an absolute path. Depending on the cluster, the header written by the service itself might have been and the apiserver proxy did rewrite the host:port to match the correct values. Unfortunately, it did not rewrite the path segment. What you expected to happen: I would expect the apiserver to rewrite the path segment of the response header so that it reflects the fact that it's proxied under the path: How to reproduce it (as minimally and precisely as possible): The path was not preserved. Anything else we need to know?: To work around this issue, a service may return strictly a relative url in the header such as: The feature to rewrite headers is quite common. For instance, Apache Httpd does it thanks to: Environment: Kubernetes version (use ):Cloud provider or hardware configuration**: custom_ OS (e.g. from /etc/os-release): Kernel (e.g. ):
/sig api-machinery /sig network
/assign
Thanks for the bug report!
GitHub didn't allow me to assign the following users: roycaihw. 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
Change:
EphemeralContainersToStart: []int{0}, }, }, <ins> "Create a new pod sandbox if the pod sandbox is dead, init container failed and RestartPolicy == OnFailure": { mutatePodFn: func(pod *v1.Pod) { pod.Spec.RestartPolicy = v1.RestartPolicyOnFailure }, mutateStatusFn: func(status *kubecontainer.PodStatus) { status.SandboxStatuses[0].State = runtimeapi.PodSandboxState_SANDBOX_NOTREADY status.ContainerStatuses = status.ContainerStatuses[3:] status.ContainerStatuses[0].ExitCode = 137 }, actions: podActions{ KillPod:                  true, CreateSandbox:            true, SandboxID:                baseStatus.SandboxStatuses[0].Id, Attempt:                  uint32(1), NextInitContainerToStart: &basePod.Spec.InitContainers[0], ContainersToStart:        []int{}, ContainersToKill:         getKillMapWithInitContainers(basePod, baseStatus, []int{}), }, }, </ins> "Kill pod and do not restart ephemeral container if the pod sandbox is dead": { mutatePodFn: func(pod *v1.Pod) { pod.Spec.RestartPolicy = v1.RestartPolicyAlways }, mutateStatusFn: func(status *kubecontainer.PodStatus) {

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: For a Pod with , kubelet would attempt to create a new sandbox for it even after all container succeeded. Logs as below: This issue is similar to which fixed the case of pods whose RestartPolicy are Never. It caused unnecessary CRI and CNI calls, confusing logs and conflicts between the routine that creates the new sandbox and the routine that kills the Pod. It's likely also the root cause of because sometimes the routine that creates the second sandbox and the routine that kills unwanted pod run concurrently, then the netns would be gone when calling CNI. What you expected to happen: kubelet shouldn't create a new sandbox for pod with RestartPolicyOnFailure if all containers succeeded How to reproduce it (as minimally and precisely as possible): Create a pod like this: Anything else we need to know?: Environment: Kubernetes version (use ): v1.18.2 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig node
Created which may fix this.
/assign
Change:
ingressPath := buildHTTPIngressPath(hostSplit[1]) ingressRule := networkingv1.IngressRule{} <del> if host != "_" { </del> <ins> if host != "" { </ins> ingressRule.Host = host }

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: kubectl create ingress panics because there is no cmdutil.AddDryRunFlag What you expected to happen: Command to work How to reproduce it (as minimally and precisely as possible): Compile the upstream, run ` Anything else we need to know?: Environment: Kubernetes version (use ): upstream/dev /sig cli /kind bug /priority critical-urgent
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
if err = testutils.WaitForPodToSchedule(testCtx.ClientSet, pod); err != nil { t.Errorf("Expected the pod to be scheduled. error: %v", err) } <ins> select { case <-postBindPlugin.pluginInvokeEventChan: case <-time.After(time.Second * 15): t.Errorf("pluginInvokeEventChan timed out") } </ins> if postBindPlugin.numPostBindCalled == 0 { t.Errorf("Expected the postbind plugin to be called, was called %d times.", postBindPlugin.numPostBindCalled) } } <del> postBindPlugin.reset() preBindPlugin.reset() </del> testutils.CleanupPods(testCtx.ClientSet, t, []*v1.Pod{pod}) }) }

Discussion:
Which jobs are flaking: ci-kubernetes-integration-master pull-kubernetes-integration Which test(s) are flaking: TestPostBindPlugin Testgrid link: Reason for failure: Anything else we need to know: links to appreciated: links to specific failures in spyglass appreciated /sig scheduling
It flaked two times recently:
Change:
"//staging/src/k8s.io/api/core/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime/schema:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/util/wait:go_default_library", </ins> "//staging/src/k8s.io/client-go/informers:go_default_library", "//staging/src/k8s.io/client-go/informers/core/v1:go_default_library", "//staging/src/k8s.io/client-go/kubernetes/fake:go_default_library",

Discussion:
What happened: kube-controller-manager with enabled option --controllers=,tokencleaner is not removing newly created tokens. It works only after kube-controller-manager restart or after editing secret with token. What you expected to happen: It should remove all expired tokens from kube-system namespace, without restarting or touching secrets. How to reproduce it (as minimally and precisely as possible): enable tokencleaner in kube-controller-manager start controller manager create bootstrap token, you can use script wait 5 minutes token is still there restart kube-controller-manager OR edit newly created token token should be gone after a while Anything else we need to know?: It could be related with Environment: Kubernetes version (use ): Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-12-03T20:56:12Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
Do you see the following log ? thanks
no errors at all
/sig auth