jiebi/CodeConvo huggingface dataset:
Change:
The 's was copied from some other, broken types. A call to is missing and therefore, for example, finalizers can be changed during a status update. That is not supposed to be possible. Object meta changes need to be removed during status updates. n/a No response Since 1.26 till at least 1.29. n/a No response No response No response No response
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 node
/assign

Discussion:
newScheduling := obj.(*resource.PodSchedulingContext) oldScheduling := old.(*resource.PodSchedulingContext) newScheduling.Spec = oldScheduling.Spec <ins> metav1.ResetObjectMetaForStatus(&newScheduling.ObjectMeta, &oldScheduling.ObjectMeta) </ins> } func (podSchedulingStatusStrategy) ValidateUpdate(ctx context.Context, obj, old runtime.Object) field.ErrorList {

"context" "errors" <ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" </ins> "k8s.io/apimachinery/pkg/fields" "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/runtime"

newClaim := obj.(*resource.ResourceClaim) oldClaim := old.(*resource.ResourceClaim) newClaim.Spec = oldClaim.Spec <ins> metav1.ResetObjectMetaForStatus(&newClaim.ObjectMeta, &oldClaim.ObjectMeta) </ins> } func (resourceclaimStatusStrategy) ValidateUpdate(ctx context.Context, obj, old runtime.Object) field.ErrorList {
Change:
it still looks like we'll be logging for every container for the whole kubelet lifetime... that seems like log spam, right? Originally posted by in
We want to only log this once on kubelet startup. Spamming the logs for every container/pod is not really that useful.
/sig node
/triage accepted /priority important-longterm IIUC this is part of the KEP graduation process (otherwise I'll have probably set priority backlog)

Discussion:
// Swap is only configured if a swap cgroup controller is available and the NodeSwap feature gate is enabled. func (m *kubeGenericRuntimeManager) configureContainerSwapResources(lcr *runtimeapi.LinuxContainerResources, pod *v1.Pod, container *v1.Container) { if !swapControllerAvailable() { <del> klog.InfoS("No swap cgroup controller present", "swapBehavior", m.memorySwapBehavior, "pod", klog.KObj(pod), "containerName", container.Name) </del> return } swapConfigurationHelper := newSwapConfigurationHelper(*m.machineInfo) if m.memorySwapBehavior == kubelettypes.LimitedSwap { if !isCgroup2UnifiedMode() {
Change:
! /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig apps
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 suspecting as cause
Ack, indeed, because this is the suite for alpha features enabled. We have this fix ready for the test itself: /cc
/cc It flakes in
/retitle [Flaking Test] [Conformance] [sig-apps] Job should apply changes to a job status
It used to fail with errors like After it fails with : [FAILED] patched object should have the applied condition with LastTransitionTime time.Date(2024, time.March, 7, 17, 58, 34, 0, time.UTC), got time.Date(2024, time.March, 7, 17, 58, 33, 0, time.Local) instead In [It] at: @ 03/07/24 17:58:34.109 Here I open the follow up fix: PTAL.

Discussion:
- testname: Jobs, apply changes to status codename: '[sig-apps] Job should apply changes to a job status [Conformance]' description: Attempt to create a running Job which MUST succeed. Attempt to patch <del> the Job status to include a new start time which MUST succeed. An annotation for the job that was patched MUST be found. Attempt to replace the job status with a new start time which MUST succeed. Attempt to read its status sub-resource which MUST succeed </del> <ins> the Job status which MUST succeed. An annotation for the job that was patched MUST be found. Attempt to replace the job status with update which MUST succeed. Attempt to read its status sub-resource which MUST succeed </ins> release: v1.24 file: test/e2e/apps/job.go - testname: Ensure Pods of an Indexed Job get a unique index.

Release: v1.24 Testname: Jobs, apply changes to status Description: Attempt to create a running Job which MUST succeed. <del> Attempt to patch the Job status to include a new start time which MUST succeed. An annotation for the job that was patched MUST be found. Attempt to replace the job status with a new start time which MUST succeed. Attempt to read its status sub-resource which MUST succeed </del> <ins> Attempt to patch the Job status which MUST succeed. An annotation for the job that was patched MUST be found. Attempt to replace the job status with update which MUST succeed. Attempt to read its status sub-resource which MUST succeed </ins> */ framework.ConformanceIt("should apply changes to a job status", func(ctx context.Context) {

if err != nil { return err } <del> if condition := findConditionByType(patchedStatus.Status.Conditions, customConditionType); condition != nil { </del> <ins> if condition := findConditionByType(statusToUpdate.Status.Conditions, customConditionType); condition != nil { </ins> condition.LastTransitionTime = now2 } else { framework.Failf("patched object does not have the required condition %v", customConditionType)
Change:
In Aldo pointed out that: Let's use that instead of sleeping. /sig node /triage accepted /priority long-term More robust test.
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : ### What would you like to be ? Aldo pointed out that: There is. There should be a Schedulable condition set to false in the PodStatus. /triage accepted /priority long-term ### Why is this needed? Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign

Discussion:
e2enode "k8s.io/kubernetes/test/e2e/framework/node" e2epod "k8s.io/kubernetes/test/e2e/framework/pod" admissionapi "k8s.io/pod-security-admission/api" <del> utilpointer "k8s.io/utils/pointer" </del> "k8s.io/utils/ptr" )

objects = append(objects, template, pod) b.create(ctx, objects...) <del> // There's no way to be sure that the scheduler has checked the pod. // But if we sleep for a short while, it's likely and if there are any // bugs that prevent the scheduler from handling creation of the class, // those bugs should show up as test flakes. // // TODO (https://github.com/kubernetes/kubernetes/issues/123805): check the Schedulable condition instead of // sleeping. time.Sleep(time.Second) </del> <ins> framework.ExpectNoError(e2epod.WaitForPodNameUnschedulableInNamespace(ctx, f.ClientSet, pod.Name, pod.Namespace)) </ins> class.UID = "" class.ResourceVersion = ""

objects = append(objects, template, pod) b.create(ctx, objects...) <del> // There's no way to be sure that the scheduler has checked the pod. // But if we sleep for a short while, it's likely and if there are any // bugs that prevent the scheduler from handling updates of the class, // those bugs should show up as test flakes. time.Sleep(time.Second) </del> <ins> framework.ExpectNoError(e2epod.WaitForPodNameUnschedulableInNamespace(ctx, f.ClientSet, pod.Name, pod.Namespace)) </ins> // Unblock the pod. class.SuitableNodes = nil

{ Name: podClaimName, Source: v1.ClaimSource{ <del> ResourceClaimTemplateName: utilpointer.String(pod.Name), </del> <ins> ResourceClaimTemplateName: ptr.To(pod.Name), </ins> }, }, }
Change:
<img width="1064" alt="image" src=""### Failure cluster /kind failing-test <!-- If this is a flake, please add: /kind flake --/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
xref:
Another cluster of failures with a different failure: <img width="1498" alt="image" src=""
PR:

Discussion:
v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/uuid" <ins> "k8s.io/kubernetes/pkg/features" </ins> "k8s.io/kubernetes/test/e2e/framework" e2epod "k8s.io/kubernetes/test/e2e/framework/pod" e2eskipper "k8s.io/kubernetes/test/e2e/framework/skipper"

}, }, } <del> pod = e2epod.NewPodClient(f).Create(ctx, pod) framework.ExpectNoError(e2epod.WaitForPodContainerToFail(ctx, f.ClientSet, pod.Namespace, pod.Name, 0, "CreateContainerConfigError", framework.PodStartShortTimeout)) var err error pod, err = f.ClientSet.CoreV1().Pods(f.Namespace.Name).Get(ctx, pod.Name, metav1.GetOptions{}) framework.ExpectNoError(err) gomega.Expect(pod.Status.ContainerStatuses[0].State.Waiting.Message).To( gomega.ContainSubstring("failed to resolve recursive read-only mode: volume "mnt" requested recursive read-only mode, but it is not read-only")) </del> <ins> _, err := f.ClientSet.CoreV1().Pods(pod.Namespace).Create(ctx, pod, metav1.CreateOptions{}) gomega.Expect(err).To(gomega.MatchError(gomega.ContainSubstring("spec.containers[0].volumeMounts.recursiveReadOnly: Forbidden: may only be specified when readOnly is true"))) </ins> }) // By // See also the unit test [pkg/kubelet.TestResolveRecursiveReadOnly] for more invalid conditions (e.g., incompatible mount propagation) }) // It }) // Context ginkgo.Context("when the runtime does not support recursive read-only mounts", func() { f.It("should accept non-recursive read-only mounts", func(ctx context.Context) { <ins> e2eskipper.SkipUnlessFeatureGateEnabled(features.RecursiveReadOnlyMounts) </ins> ginkgo.By("waiting for the node to be ready", func() { waitForNodeReady(ctx) if supportsRRO(ctx, f) {

}) // By }) // It f.It("should reject recursive read-only mounts", func(ctx context.Context) { <ins> e2eskipper.SkipUnlessFeatureGateEnabled(features.RecursiveReadOnlyMounts) </ins> ginkgo.By("waiting for the node to be ready", func() { waitForNodeReady(ctx) if supportsRRO(ctx, f) {
Change:
integration TestRatchetingFunctionality/Enum TestRatchetingFunctionality/MinPropertiesMaxProperties TestRatchetingFunctionality/CELOptionalOldSelf TestRatchetingFunctionality/ TestRatchetingFunctionality/ since 3/8 No response /sig api-machinery
/assign /triage accepted

Discussion:
} uuidString := string(uuid.NewUUID()) <del> // UUID string is just hex separated by dashes, which is safe to // throw into regex like this pattern := "^" + uuidString + "$" </del> sentinelName := "__ratcheting_sentinel_field__" sch.Properties[sentinelName] = apiextensionsv1.JSONSchemaProps{ <del> Type:    "string", Pattern: pattern, // Put MaxLength condition inside AllOf since the string_validator // in kube-openapi short circuits upon seeing MaxLength, and we // want both pattern and MaxLength errors AllOf: []apiextensionsv1.JSONSchemaProps{ { MinLength: ptr((int64(1))), // 1 MinLength to prevent empty value from ever being admitted MaxLength: ptr((int64(0))), // 0 MaxLength to prevent non-empty value from ever being admitted }, }, </del> <ins> Type: "string", Enum: []apiextensionsv1.JSON{{ Raw: []byte(`"` + uuidString + `"`), }}, </ins> } for _, v := range myCRD.Spec.Versions {

} // Keep trying to create an invalid instance of the CRD until we <del> // get an error containing the ResourceVersion we are looking for </del> <ins> // get an error containing the message we are looking for </ins> // counter := 0 return wait.PollUntilContextCancel(context.TODO(), 100*time.Millisecond, true, func(_ context.Context) (done bool, err error) {

gvr:  myCRDV1Beta1, name: "sentinel-resource", patch: map[string]interface{}{ <del> // Just keep using different values sentinelName: fmt.Sprintf("invalid %v %v", uuidString, counter), </del> <ins> sentinelName: fmt.Sprintf("invalid-%d", counter), </ins> }}.Do(ctx) if err == nil {
Change:
=== RUN TestStructuredAuthenticationConfigReload/oldinvalidconfigtonewvalidconfig first seen in 3/11 No response /sig api-machinery instrumentation
/sig auth /remove-sig api-machinery instrumentation /triage accepted /assign

Discussion:
_, err = client.CoreV1().Pods(defaultNamespace).List(ctx, metav1.ListOptions{}) tt.assertErrFn(t, err) <del> err = os.WriteFile(apiServer.ServerOpts.Authentication.AuthenticationConfigFile, []byte(tt.newAuthConfigFn(t, oidcServer.URL(), string(caCert))), 0600) </del> <ins> // Create a temporary file tempFile, err := os.CreateTemp("", "tempfile") require.NoError(t, err) defer func() { _ = tempFile.Close() }() // Write the new content to the temporary file _, err = tempFile.Write([]byte(tt.newAuthConfigFn(t, oidcServer.URL(), string(caCert)))) require.NoError(t, err) // Atomically replace the original file with the temporary file err = os.Rename(tempFile.Name(), apiServer.ServerOpts.Authentication.AuthenticationConfigFile) </ins> require.NoError(t, err) if tt.waitAfterConfigSwap {
Change:
There is a minor translation issue about in Japanese. Output of and are completely same. means cluster in japanese, so it must be
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
/sig docs

Discussion:
# https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/cmd/config/delete_cluster.go#L38 #: staging/src/k8s.io/kubectl/pkg/cmd/config/delete_cluster.go:42 msgid "Delete the specified cluster from the kubeconfig" <del> msgstr "指定したコンテキストをkubeconfigから削除する" </del> <ins> msgstr "指定したクラスターをkubeconfigから削除する" </ins> # https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/cmd/config/delete_context.go#L38 #: staging/src/k8s.io/kubectl/pkg/cmd/config/delete_context.go:42
Change:
storageversionmigrator TestStorageVersionMigrationWithCRD Added with 03-09. /cc /sig api-machinery
/assign as the feature owner. Thank you. /triage accepted
Can you please confirm what type of flake this is? Is it due to a bug, improper test, etc? I am assuming this won't block upcoming release cuts. Is that correct?
Looking at the logs, the actual failure is here that's from which is failing after the 30s context deadline.
(03-24)failed after was merged(03-19) (03-20)
/reopen
Reopened this issue. <detailsIn response to : /reopen </details
do you have any update or plan on this? The flake rate is about once a day on
addressed the first flake with context deadline. to address the new flakes:
Thanks for the update. No flake until now.
Just ran into a presubmit failure that looks similar, is this the same issue?
PTAL!
/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
/reopen Looks like it's still flaking -
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
The test is continue flaking today. Recent failures: Triage Error is quite similar to the one above Seems like this test is still failed with the same issue until now. cc cc
/reopen cc This failed again
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

Discussion:
"time" clientv3 "go.etcd.io/etcd/client/v3" corev1 "k8s.io/api/core/v1" svmv1alpha1 "k8s.io/api/storagemigration/v1alpha1" apiextensionsv1 "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1"

err := wait.PollUntilContextTimeout( ctx, 500*time.Millisecond, <del> wait.ForeverTestTimeout, </del> <ins> 1*time.Minute, </ins> true, func(ctx context.Context) (bool, error) { triggerCR := svm.createCR(ctx, t, "triggercr", "v1")
Change:
storageversionmigrator TestStorageVersionMigrationWithCRD Added with 03-09. /cc /sig api-machinery
/assign as the feature owner. Thank you. /triage accepted
Can you please confirm what type of flake this is? Is it due to a bug, improper test, etc? I am assuming this won't block upcoming release cuts. Is that correct?
Looking at the logs, the actual failure is here that's from which is failing after the 30s context deadline.
(03-24)failed after was merged(03-19) (03-20)
/reopen
Reopened this issue. <detailsIn response to : /reopen </details
do you have any update or plan on this? The flake rate is about once a day on
addressed the first flake with context deadline. to address the new flakes:
Thanks for the update. No flake until now.
Just ran into a presubmit failure that looks similar, is this the same issue?
PTAL!
/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
/reopen Looks like it's still flaking -
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
The test is continue flaking today. Recent failures: Triage Error is quite similar to the one above Seems like this test is still failed with the same issue until now. cc cc
/reopen cc This failed again
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

Discussion:
t.Fatalf("Failed to get CRD: %v", err) } <ins> // TODO: wrap all actions after updateCRD with wait loops so we do not need this sleep //  it is currently necessary because we update the CRD but do not otherwise guarantee that the updated config is active time.Sleep(10 * time.Second) </ins> return crd }
Change:
storageversionmigrator TestStorageVersionMigrationWithCRD Added with 03-09. /cc /sig api-machinery
/assign as the feature owner. Thank you. /triage accepted
Can you please confirm what type of flake this is? Is it due to a bug, improper test, etc? I am assuming this won't block upcoming release cuts. Is that correct?
Looking at the logs, the actual failure is here that's from which is failing after the 30s context deadline.
(03-24)failed after was merged(03-19) (03-20)
/reopen
Reopened this issue. <detailsIn response to : /reopen </details
do you have any update or plan on this? The flake rate is about once a day on
addressed the first flake with context deadline. to address the new flakes:
Thanks for the update. No flake until now.
Just ran into a presubmit failure that looks similar, is this the same issue?
PTAL!
/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
/reopen Looks like it's still flaking -
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
The test is continue flaking today. Recent failures: Triage Error is quite similar to the one above Seems like this test is still failed with the same issue until now. cc cc
/reopen cc This failed again
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

Discussion:
err := wait.PollUntilContextTimeout( ctx, 500*time.Millisecond, <del> wait.ForeverTestTimeout, </del> <ins> time.Second*60, </ins> true, func(ctx context.Context) (bool, error) { apiGroups, _, err := svm.discoveryClient.ServerGroupsAndResources()
Change:
Internal CI for ppc64le arch : https://prow.ppc64le- cacher Failure is observed on Mar 18th No response 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
This test is flaking with data race as is getting accessed for field without obtaining locks in I am thinking to raise a PR to add necessary locks for different /cc
/assign

Discussion:
ResourceVersion:   "105", }, verifyBackingStore: func(t *testing.T, s *dummyStorage) { <del> require.NotEqual(t, 0, s.requestWatchProgressCounter, "expected store.RequestWatchProgressCounter to be > 0. It looks like watch progress wasn't requested!") </del> <ins> require.NotEqual(t, 0, s.getRequestWatchProgressCounter(), "expected store.RequestWatchProgressCounter to be > 0. It looks like watch progress wasn't requested!") </ins> }, },