jiebi/CodeConvo huggingface dataset:
Change:
This line reads as if the bound has already happened: But, if I read correctly, the bound happens immediately after: And there is even a wait for confirmation after: The log line to better describe the actual state and another log line at V(2) to confirm that the operation ended. No response all supported versions <details</details<details</details<details</details<details</details<details</details
/sig storage
cc
/triage accepted

Discussion:
// Do the actual prebinding. Let the PV controller take care of the rest // There is no API rollback if the actual binding fails for _, binding = range bindings { <del> klog.V(5).InfoS("bindAPIUpdate: binding PV to PVC", "pod", klog.KObj(pod), "PV", klog.KObj(binding.pv), "PVC", klog.KObj(binding.pvc)) </del> // TODO: does it hurt if we make an api call and nothing needs to be updated? <del> klog.V(2).InfoS("Claim bound to volume", "PVC", klog.KObj(binding.pvc), "PV", klog.KObj(binding.pv)) </del> <ins> klog.V(5).InfoS("Updating PersistentVolume: binding to claim", "pod", klog.KObj(pod), "PV", klog.KObj(binding.pv), "PVC", klog.KObj(binding.pvc)) </ins> newPV, err := b.kubeClient.CoreV1().PersistentVolumes().Update(ctx, binding.pv, metav1.UpdateOptions{}) if err != nil { <del> klog.V(4).InfoS("Updating PersistentVolume: binding to claim failed", "PV", klog.KObj(binding.pv), "PVC", klog.KObj(binding.pvc), "err", err) </del> <ins> klog.V(4).InfoS("Updating PersistentVolume: binding to claim failed", "pod", klog.KObj(pod), "PV", klog.KObj(binding.pv), "PVC", klog.KObj(binding.pvc), "err", err) </ins> return err } <del> klog.V(4).InfoS("Updating PersistentVolume: bound to claim", "PV", klog.KObj(binding.pv), "PVC", klog.KObj(binding.pvc)) </del> <ins> klog.V(2).InfoS("Updated PersistentVolume with claim. Waiting for binding to complete", "pod", klog.KObj(pod), "PV", klog.KObj(binding.pv), "PVC", klog.KObj(binding.pvc)) </ins> // Save updated object from apiserver for later checking. binding.pv = newPV lastProcessedBinding++

} // All pvs and pvcs that we operated on are bound <del> klog.V(4).InfoS("All PVCs for pod are bound", "pod", klog.KObj(pod)) </del> <ins> klog.V(2).InfoS("All PVCs for pod are bound", "pod", klog.KObj(pod)) </ins> return true, nil }
Change:
We observed that when deplying manifests to a cluster running 1.26.1-gke.200, the StorageClass and PVC get created successfully. However, the PVC is stuck in a Pending state and no PV is provisioned. The workaround is to add storageClassName to one of the pending PVCs on cluster, and it did go from Pending to properly provisioned a PV and reaching Bound state. We looked at the logs and found that according to the doc: , Is this annotation is fully deprecated in the new 1.26.1 release? If yes can we add this detail to documentation or release note? the PVC should not stuck in a Pending state and PV is provisioned in 1.26.1 a 1.26.1-gke.200 cluster in GKE via yaml The error comes form the code: and There are some hypotheses here: The annotation does not work on 1.26.1 any more, so a default storage class is being populated to the PVC. For some reason, the did not work, so the PVC was deployed with an empty StorageClass nil. Then the kube controller manager tried to update the PVC with the default StorageClass, which triggered the error: <details</details<detailsGKE </details<details</details<details</details<details</details<details</details
/sig storage
Annotation support seem to be still intact. Check the e2e test
From the point of view of the code, this annotation is still in use. I'll try to see if I can reproduce it.
It's a bug introduced in The feature is enabled in 1.26 by default.
/triage accepted

Discussion:
// Ignores claims that already have a storage class. // TODO: if resync is ever changed to a larger period, we might need to change how we set the default class on existing unbound claims func (ctrl *PersistentVolumeController) assignDefaultStorageClass(claim *v1.PersistentVolumeClaim) (bool, error) { <del> if claim.Spec.StorageClassName != nil { </del> <ins> if storagehelpers.GetPersistentVolumeClaimClass(claim) != "" { </ins> return false, nil }

}, }, }, <ins> { storageClasses: []*storagev1.StorageClass{ makeDefaultStorageClass(classGold, &modeImmediate), makeStorageClass(classCopper, &modeImmediate), }, tests: []controllerTest{ { name:            "15-7 - pvc storage class is not changed if claim is not bound but already set annotation "volume.beta.kubernetes.io/storage-class"", initialVolumes:  novolumes, expectedVolumes: novolumes, initialClaims:   newClaimArray("claim15-7", "uid15-7", "1Gi", "", v1.ClaimPending, nil, v1.BetaStorageClassAnnotation), expectedClaims:  newClaimArray("claim15-7", "uid15-7", "1Gi", "", v1.ClaimPending, nil, v1.BetaStorageClassAnnotation), expectedEvents:  noevents, errors:          noerrors, test:            testSyncClaim, }, }, }, </ins> } for _, test := range tests { runSyncTests(t, test.tests, test.storageClasses, nil)
Change:
I am working on a PR where I am removing some legacy code from a API. I believe I have to run some scripts to generate code. When I run I get the following error: I expect the script to work and run without error. Run hack/update- or run I am on the latest build. <details</details<details</details<details</details<details</details<details</details<details</details
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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 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
cc are you synced to HEAD of master? what version of bash are you running?
I am synced to HEAD of master and my bash version is version 4.2.46(2).
Pretty sure identified it correctly as a bash version issue. I ran into this issue and it was due to using an older bash. I know that 4.2.46 (which is used in AL2) is too old, but I'm not sure exactly what the minimum version is. If you are using AL2 for development, this will drop in a compatible version:
/kind support
Let me see if there's a way to make old-bash shut up. Sadly I do not have an old version to try against - - are you willing to type commands into your shell for me?
Yep, you just caught me before I purged my old environment with suggestions.
would a slack conversation be easier?
maybe but I am juggling meetings :)
There are a few problems I ran into before just deciding to upgrade to bash v5, but I think this initial thing was a bug fixed in bash 4.4+: From, when the nounset option is enabled no longer throws an unbound variable error. So on 4.2, this fails:
working on a patch

Discussion:
print_codegens exit 1 fi <del> codegens_to_run+=("${matches[@]}") </del> <ins> # The array-syntax abomination is to accommodate older bash. codegens_to_run+=("${matches[@]:+"${matches[@]}"}") </ins> done # If no codegens were specified, run them all.

fi for g in "${codegens_to_run[@]}"; do <del> "codegen::${g}" "${flags_to_pass[@]}" </del> <ins> # The array-syntax abomination is to accommodate older bash. "codegen::${g}" "${flags_to_pass[@]:+"${flags_to_pass[@]}"}" </ins> done
Change:
After , /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

Discussion:
"k8s.io/apimachinery/pkg/util/wait" "k8s.io/apimachinery/pkg/watch" v1core "k8s.io/client-go/kubernetes/typed/core/v1" <ins> "k8s.io/client-go/util/retry" </ins> "k8s.io/kubernetes/pkg/kubelet/events" "k8s.io/kubernetes/test/e2e/framework" e2ekubelet "k8s.io/kubernetes/test/e2e/framework/kubelet"

framework.Failf("pod spec TerminationGracePeriodSeconds is not 1: %d", *pod.Spec.TerminationGracePeriodSeconds) } <del> time.Sleep(5 * time.Second) pod, err = podClient.Get(ctx, pod.Name, metav1.GetOptions{}) framework.ExpectNoError(err, "failed to query for pod") ginkgo.By("updating the pod to have a negative TerminationGracePeriodSeconds") pod.Spec.TerminationGracePeriodSeconds = utilpointer.Int64(-1) _, err = podClient.PodInterface.Update(ctx, pod, metav1.UpdateOptions{}) </del> <ins> // retry if the TerminationGracePeriodSeconds is overrided // see more in https://github.com/kubernetes/kubernetes/pull/115606 err = retry.RetryOnConflict(retry.DefaultBackoff, func() error { pod, err := podClient.Get(ctx, pod.Name, metav1.GetOptions{}) framework.ExpectNoError(err, "failed to query for pod") ginkgo.By("updating the pod to have a negative TerminationGracePeriodSeconds") pod.Spec.TerminationGracePeriodSeconds = utilpointer.Int64(-1) _, err = podClient.PodInterface.Update(ctx, pod, metav1.UpdateOptions{}) return err }) </ins> framework.ExpectNoError(err, "failed to update pod") pod, err = podClient.Get(ctx, pod.Name, metav1.GetOptions{})
Change:
PR was reverted by because it (erroneously) relied on OpenAPIV3 feature to be enabled, but would non-deterministically leave the feature disabled after running. I tracked it down to the fact that this test disables all or features in a loop which iterates over a , which are known to have unstable iteration order: When key is processed before key , then would disable before s default value is to be saved. Normally, ignores features that have been explicitly set, so it only affects those which fall back on the value. But this issue does not just affect but any non-GA feature. I suggest the loop in be made to skip the special feature keys such as . /cc /cc The value before every feature gate should be restored after running . This test always fails on my machine (just pasted it into ): No response <details</details<details</details<details</details<details</details<details</details<details</details
/assign
Wow, good catch, sorry to make you track down what turned out to be a bug in our test
/sig auth
/area test
/triage accepted

Discussion:
func TestPodSecurityGAOnly(t *testing.T) { // Disable all alpha and beta features for k, v := range utilfeature.DefaultFeatureGate.DeepCopy().GetAll() { <del> if v.PreRelease == featuregate.Alpha || v.PreRelease == featuregate.Beta { </del> <ins> if k == "AllAlpha" || k == "AllBeta" { // Skip special features. When processed first, special features may // erroneously disable other features. continue } else if v.PreRelease == featuregate.Alpha || v.PreRelease == featuregate.Beta { </ins> defer featuregatetesting.SetFeatureGateDuringTest(t, utilfeature.DefaultFeatureGate, k, false)() } }
Change:
TestConnectionPings Not sure pull-kubernetes-unit /sig api-machinery
/cc
failed again. It seems to flake more recently.
hmmm this was failing for some time /cc
cc
interesting
the only thing that I see can happen is that the connection takes time to be established
/assign
still flaking -
/triage accepted
Still flake during the batch run for merge pool.
I'm starting to think if there are something going on with the library in go or we are having pauses on CI or something weird is going because I've seen a considerable number of flakes with tests that pass locally running with and race detectors but keep failing in CI
/close According to the storage Google APIs statistics, this does not occur in the master anymore.
Closing this issue. <detailsIn response to : /close According to the storage Google APIs statistics, this does not occur in the master anymore. </details
The is flaking again. ^^ shows many flakes. !
those failues are only happening in old branches, not in master
Do we know the fix that could be picked to the release branches?
And does the stress command in reproduce a flake on master?
We saw this flake in our internal job that runs k8s master UT with golang tip version https://prow.ppc64le- Yes, I was able to reproduce this failure locally using the master of k8s and with released/tip golang. But unable to see the flakiness now on k8s master!!
shows it flake on v1.27 release branch only.

Discussion:
t.Fatalf("client: error connecting to proxy: %v", err) } defer clConn.Close() <del> start := time.Now() </del> clSPDYConn, err := NewClientConnection(clConn) if err != nil { t.Fatalf("client: error creating spdy connection: %v", err) } defer clSPDYConn.Close() <ins> start := time.Now() </ins> clSPDYStream, err := clSPDYConn.CreateStream(http.Header{}) if err != nil { t.Fatalf("client: error creating stream: %v", err)
Change:
a test that is flaking at a ~3% failure rate with : Originally posted by in /sig api-machinery /assign /cc /kind failing-test
/assign

all the failures I've seen weren't failures, but rather timeouts. I wasn't able to reproduce it either by running the test itself, but I know what the potential failure is here: the and goroutines are somehow finishing the last one that is called is 1+ of goroutine is starting after that In this case the last will never finish. The fix is in
not sure if it's related, but TestGetCurrentResourceVersionFromStorage in the same package started flaking at the same time: looks like the fix in won't address that one
that's a different thing for sure. - can you please take a look at it - it's a newly test from yesterday
Spinned of for the other issue mentioned by Jordan.

Discussion:
import ( "context" <ins> "sync" </ins> "testing" "time" )

errCh := make(chan error, concurrency) ready := newReady() ready.set(false) <ins> wg := sync.WaitGroup{} wg.Add(2 * concurrency) </ins> for i := 0; i < concurrency; i++ { go func() { errCh <- ready.wait(context.Background()) }() go func() { <ins> defer wg.Done() </ins> ready.set(false) }() go func() { <ins> defer wg.Done() </ins> ready.set(true) }() } <ins> // Last one has to be set to true. wg.Wait() </ins> ready.set(true) for i := 0; i < concurrency; i++ { if err := <-errCh; err != nil { t.Errorf("unexpected error %v on channel %d", err, i)
Change:
kubectl apply performs validation before the apply. Non-CRD resources (e.g. pods / deployments) don't need CRD schema for validation, but if we use resource, kubectl calls . In my Kubernetes cluster, administrator doesn't allow users to list CRDs, so user cannot apply non-CRD resources (e.g. pods / deployments) with resource. doesn't happen because we're going to apply two Deployments. should not happen because we're going to apply two Deployments. No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig cli
/triage accepted /assign
/priority backlog

Discussion:
// HasSupport checks if the given gvk supports the query param configured on v func (v *QueryParamVerifier) HasSupport(gvk schema.GroupVersionKind) error { <ins> if (gvk == schema.GroupVersionKind{Version: "v1", Kind: "List"}) { return NewParamUnsupportedError(gvk, v.queryParam) } </ins> oapi, err := v.openAPIGetter.OpenAPISchema() if err != nil { return fmt.Errorf("failed to download openapi: %v", err)

supports:   false, queryParam: QueryParamFieldValidation, }, <ins> { gvk: schema.GroupVersionKind{ Group:   "", Version: "v1", Kind:    "List", }, success:    false, supports:   false, queryParam: QueryParamFieldValidation, }, </ins> } for _, test := range tests {

if err == nil { t.Fatalf("Random doesn't support fieldValidation, yet no error found") } <ins> err = fieldValidationVerifier.HasSupport(schema.GroupVersionKind{Group: "", Version: "v1", Kind: "List"}) if err == nil { t.Fatalf("List does not support fieldValidation, yet no error found") } </ins> } type EmptyOpenAPI struct{}

if err == nil { t.Fatalf("MyCRD doesn't support fieldValidation, yet no error found") } <ins> err = fieldValidationVerifier.HasSupport(schema.GroupVersionKind{Group: "", Version: "v1", Kind: "List"}) if err == nil { t.Fatalf("List does not support fieldValidation, yet no error found") } </ins> }
Change:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
/triage accepted
/assign
This appears to be due to timeout being reached and the kubelet not updating the status of the terminated pod in time before the timeout is hit.
Testgrid: and

Discussion:
const ( pollInterval                 = 1 * time.Second <del> podStatusUpdateTimeout       = 10 * time.Second </del> <ins> podStatusUpdateTimeout       = 30 * time.Second </ins> priorityClassesCreateTimeout = 10 * time.Second )

period5Name, periodC5Name, <del> period5Name, </del> <ins> periodB5Name, </ins> }, { period5Name, periodC5Name, <del> period5Name, </del> <ins> periodB5Name, </ins> periodA5Name, }, { period5Name, periodC5Name, <del> period5Name, </del> <ins> periodB5Name, </ins> periodA5Name, periodCritical5Name, },
Change:
https://perf- /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig scheduling <!-- Please assign a SIG using: /sig SIG-NAME --
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
/cc
The goleak check was in
cc
cc
At least didn't fail with a goroutine leak. It failed because of:
Good to see it's not a regression. Let me raise a PR to see whether is the only culprit.
Even if it's not the only culprit, I wouldn't think this is a regression, but rather a consequence of the fact that we didn't use goleak before.
it's just coincidental gets merged at the same timing of the goleak check PR. In other words, the scheduler perf test would also fail if the goleak PR didn't go in.
This can be solved by removing this line

Discussion:
measurePods: 1000 - name: SchedulingMigratedInTreePVs <del> featureGates: CSIMigrationAWS: true </del> workloadTemplate: - opcode: createNodes countParam: $initNodes
Change:
integration-master TestCronJobLaunchesPodAndCleansUp test increased from ~30 seconds to ~90 seconds Since merging This was reported in /sig apps /wg structured-logging
/milestone v1.27
/sig apps /wg structured-logging
It's caused by reordering the context cancellation in the test. I have a fix. /assign
/triage accepted

Discussion:
closeFn, cjc, jc, informerSet, clientSet := setup(ctx, t) defer closeFn() <ins> // When shutting down, cancel must be called before closeFn. // We simply call it multiple times. defer cancel() </ins> cronJobName := "foo" namespaceName := "simple-cronjob-test"
Change:
We have already quite a few podresources-related e2e tests. We should promote some among the most stable subset of them as NodeConformance. This is especially useful considering the plans to move . According to testgrid some possible candidates are: [sig-node] POD Resources [Serial] [Feature:PodResources][NodeFeature:PodResources] when querying /metrics should report the values for the podresources metrics [sig-node] POD Resources [Serial] [Feature:PodResources][NodeFeature:PodResources] without SRIOV devices in the system with CPU manager None policy should return the expected responses As part of the we want to enable the endpoint also on windows, where . Windows lanes run tests. We already have some podresources e2e tests, and promoting them to will enables us to both ensuring the code keeps working on windows, where it was exercised way less, and increase the stability of the codebase.
/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
/assign
Thanks for the quick review! I'll keep an eye on the lanes and prep the trivial revert in cause of any issue.

Discussion:
}) }) <del> ginkgo.Context("when querying /metrics", func() { </del> <ins> ginkgo.Context("when querying /metrics [NodeConformance]", func() { </ins> ginkgo.BeforeEach(func(ctx context.Context) { // ensure APIs have been called at least once endpoint, err := util.LocalEndpoint(defaultPodResourcesPath, podresources.Socket)
Change:
We observed degradation in scheduling throughput, putting it under 100 pods/s pprof points to ! /sig scheduling /kind regression 100 pods/s N/A No response <details</details<detailsN/A </details<details</details<details</details<details</details<details</details
/assign cc
/triage accepted
Oh.. sorry for the degradation and thanks for working on this. This time, as goroutine metric is called every time goroutine is created, we observed the clear performance degradation. But, there are actually many other metrics which is stored directly by calling everytime. So, for the future direction, is it better (slightly?) for the performance to move all other metrics to store via ? (like metric)
No need to be sorry. Just tagging you as FYI so that we are aware of this kind of performance penalties in future reviews :)
No, this code is too complex to be worth it. The rest of the metrics usage doesn't show up in pprofs, so no need to optimize further for now. We just need to be diligent not to call within critical routines when they all share the same values.

Discussion:
// Until is a wrapper around workqueue.ParallelizeUntil to use in scheduling algorithms. // A given operation will be a label that is recorded in the goroutine metric. func (p Parallelizer) Until(ctx context.Context, pieces int, doWorkPiece workqueue.DoWorkPieceFunc, operation string) { <ins> goroutinesMetric := metrics.Goroutines.WithLabelValues(operation) </ins> withMetrics := func(piece int) { <del> metrics.Goroutines.WithLabelValues(operation).Inc() defer metrics.Goroutines.WithLabelValues(operation).Dec() </del> <ins> goroutinesMetric.Inc() </ins> doWorkPiece(piece) <ins> goroutinesMetric.Dec() </ins> } workqueue.ParallelizeUntil(ctx, p.parallelism, pieces, withMetrics, workqueue.WithChunkSize(chunkSizeFor(pieces, p.parallelism)))