jiebi/CodeConvo huggingface dataset:
Change:
And others: /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:
memoryLimit := memoryCapacity.Value() matchResourceMetrics := gomega.And(gstruct.MatchKeys(gstruct.IgnoreMissing, gstruct.Keys{ <del> "scrape_error": gstruct.Ignore(), </del> <ins> "scrape_error":          gstruct.Ignore(), "resource_scrape_error": gstruct.Ignore(), </ins> "node_cpu_usage_seconds_total": gstruct.MatchAllElements(nodeID, gstruct.Elements{ "": boundedSample(1, 1e6), }),

fmt.Sprintf("%s::%s", f.Namespace.Name, pod1): boundedSample(0*e2evolume.Kb, 80*e2evolume.Mb), }), }), <del> haveKeys("scrape_error", "node_cpu_usage_seconds_total", "node_memory_working_set_bytes", "container_cpu_usage_seconds_total", </del> <ins> haveKeys("scrape_error", "resource_scrape_error", "node_cpu_usage_seconds_total", "node_memory_working_set_bytes", "container_cpu_usage_seconds_total", </ins> "container_memory_working_set_bytes", "container_start_time_seconds", "pod_cpu_usage_seconds_total", "pod_memory_working_set_bytes"), ) ginkgo.By("Giving pods a minute to start up and produce metrics")
Change:
pull-kubernetes-unit see title 8/17? ref No response /sig instrumentation
/triage accepted /assign
an example flake in of sig-release/master-blocking test grid. (It flakes a few times, and it is not a blocker.)
/cc still flake
I tested it locally, and it did reproduce the error. I'll take a look at this problem.
I looked into this part of the code. The problem should be the loss of precision. as the denominator of is too large, that is to say, occasionally satisfies the condition( ≈0.16%), and the allowed precision error is too small. So, occasionally this test flakes. I modified the code and printed out the results of in the log(It can be seen that the value is greater than ): see stress test result details from the . I don't know much about this, how did you decide to use as the denominator? Maybe we can adjust the precision error( for example 1e-14 -1e-13 or other value)? Can you take a look? FYI: In the prometheus histogram test , this error value is set to
I do not recall exactly how I arrived at the limit of 1e-14. That is about 46.5 bits, which should be well within the accuracy of a . To get this test passing, I have increased the limit by a factor of 10 (in ), based on the relative errors reported above.

Discussion:
for _, term := range terms { ee.sum += term } <del> t.Logf("Adding expectation %#+v", ee) </del> <ins> t.Logf("At idx=%v, adding expectation of buckets=%#+v, upperBounds=%#+v, sum=%v, count=%v", whIdx, ee.buckets, ee.upperBounds, ee.sum, ee.count) </ins> expectations = append(expectations, ee) } // Do the planned calls on ObserveWithWeight, in randomized order

actualSum := actualHist.GetSampleSum() num := math.Abs(actualSum - ee.sum) den := math.Max(math.Abs(actualSum), math.Abs(ee.sum)) <del> if num > den/1e14 { t.Errorf("At idx=%d, expected sum %v but got %v, err=%v", idx, ee.sum, actualSum, actualSum-ee.sum) </del> <ins> relErr := num / den // Issue 120112 reports relative errors as high as 9.55994394104272e-14 if relErr > 1e-13 { t.Errorf("At idx=%d, expected sum %v but got %v, err=%v, relativeErr=%v", idx, ee.sum, actualSum, actualSum-ee.sum, relErr) </ins> } } }
Change:
Logs look like: originally mentioned in started a WIP PR to recreate, please see: /sig cloud-provider /sig testing cc
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
more comments on the original issue, it may be possible that error is a symton and the root cause is on the installation process
xref:

Discussion:
# and kubelet export CLOUD_PROVIDER_FLAG="${CLOUD_PROVIDER_FLAG:-external}" <ins> # Don't run the node-ipam-controller on the KCM if cloud-provider external if [[ "${CLOUD_PROVIDER_FLAG}" ==  "external" ]]; then RUN_CONTROLLERS="${RUN_CONTROLLERS:-*,-node-ipam-controller}" fi </ins> # When ENABLE_AUTH_PROVIDER_GCP is set, following flags for out-of-tree credential provider for GCP # are presented to kubelet: # --image-credential-provider-config=${path-to-config}
Change:
/kind failing-test /kind flake /sig node /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

Discussion:
"k8s.io/kubernetes/pkg/scheduler/framework/plugins/feature" "k8s.io/kubernetes/pkg/scheduler/framework/plugins/names" schedutil "k8s.io/kubernetes/pkg/scheduler/util" <ins> "k8s.io/utils/ptr" </ins> ) const (

claim := state.claims[index] if len(claim.Status.ReservedFor) == 0 || len(claim.Status.ReservedFor) == 1 && claim.Status.ReservedFor[0].UID == pod.UID { <ins> // Before we tell a driver to deallocate a claim, we // have to stop telling it to allocate. Otherwise, // depending on timing, it will deallocate the claim, // see a PodSchedulingContext with selected node, and // allocate again for that same node. if state.podSchedulingState.schedulingCtx != nil && state.podSchedulingState.schedulingCtx.Spec.SelectedNode != "" { state.podSchedulingState.selectedNode = ptr.To("") if err := state.podSchedulingState.publish(ctx, pod, pl.clientset); err != nil { return nil, statusError(logger, err) } } </ins> claim := state.claims[index].DeepCopy() claim.Status.DeallocationRequested = true claim.Status.ReservedFor = nil
Change:
master-blocking: ! 2023-09-04 01:09:55 +0000 UTC No response /sig scheduling
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
most of the failures are not the scheduling test. it's
I guess not related to sig-scheduling since pods are created in kube-system? (supplement: the test code lastest changed was 2 months ago for library deprecation).
so, based on lubomir's comment the problem seem to be the fluentd pods
Sep 7 05:02:41.051: INFO: fluentd-gcp-v3.2.0-zkkj2 Pending [{PodScheduled False 0001-01-01 00:00:00 +0000 UTC 2023-09-07 04:51:10 +0000 UTC Unschedulable 0/4 nodes are available: 1 Insufficient cpu. preemption: 0/4 nodes are available: 1 No preemption victims found for incoming pod, 3 node(s) didn't match Pod's node affinity/selector.}]
the tests are a red herring, the problem is the job , can you please retitle to reflect it?
/remove-sig scheduling /sig cloud-provider
it fails to be scheduled in the master vm because of lack of cpu
The master vm only has 1 cpu, but I can't understand why it started to fail
Looks like this is passing now

Discussion:
env: # Defaults, used if no overrides are found in fluentd-gcp-scaling-policy - name: CPU_REQUEST <del> value: 100m </del> <ins> value: 10m </ins> - name: MEMORY_REQUEST value: 200Mi - name: CPU_LIMIT
Change:
[X] test approval issue : [X] test pr : [X] two weeks soak end date : 22 Sept 2023 [X] test promotion pr : [X] remove endpoint from According to following APIsnoop query, there are three StorageClass endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 7 endpoints. The e2e logs for this test are listed below. This query shows the following StorageClass endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 7 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted /cc
/sig storage
/reopen For tracking the rest of the steps to Promotion
Reopened this issue. <detailsIn response to : /reopen For tracking the rest of the steps to Promotion 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:
to delete the secret, the deletion must succeed. release: v1.21 file: test/e2e/common/storage/secrets_volume.go <ins> - testname: StorageClass, lifecycle codename: '[sig-storage] StorageClasses CSI Conformance should run through the lifecycle of a StorageClass [Conformance]' description: Creating a StorageClass MUST succeed. Reading the StorageClass MUST succeed. Patching the StorageClass MUST succeed with its new label found. Deleting the StorageClass MUST succeed and it MUST be confirmed. Replacement StorageClass MUST be created. Updating the StorageClass MUST succeed with its new label found. Deleting the StorageClass via deleteCollection MUST succeed and it MUST be confirmed. release: v1.29 file: test/e2e/storage/storageclass.go </ins> - testname: 'SubPath: Reading content from a configmap volume.' codename: '[sig-storage] Subpath Atomic writer volumes should support subpaths with configmap pod [Conformance]'

f.NamespacePodSecurityLevel = admissionapi.LevelBaseline ginkgo.Describe("CSI Conformance", func() { <del> ginkgo.It("should run through the lifecycle of a StorageClass", func(ctx context.Context) { </del> <ins> /* Release: v1.29 Testname: StorageClass, lifecycle Description: Creating a StorageClass MUST succeed. Reading the StorageClass MUST succeed. Patching the StorageClass MUST succeed with its new label found. Deleting the StorageClass MUST succeed and it MUST be confirmed. Replacement StorageClass MUST be created. Updating the StorageClass MUST succeed with its new label found. Deleting the StorageClass via deleteCollection MUST succeed and it MUST be confirmed. */ framework.ConformanceIt("should run through the lifecycle of a StorageClass", func(ctx context.Context) { </ins> scClient := f.ClientSet.StorageV1().StorageClasses() var initialSC, replacementSC *storagev1.StorageClass
Change:
[X] test approval issue : [X] test pr : [X] two weeks soak end date : 22 Sept 2023 [X] test promotion pr : [X] remove endpoint from According to following APIsnoop query, there are three StorageClass endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 7 endpoints. The e2e logs for this test are listed below. This query shows the following StorageClass endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 7 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted /cc
/sig storage
/reopen For tracking the rest of the steps to Promotion
Reopened this issue. <detailsIn response to : /reopen For tracking the rest of the steps to Promotion 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:
- createCoreV1Node - createCoreV1PersistentVolume - createStorageV1CSINode <del> - createStorageV1StorageClass </del> - createStorageV1VolumeAttachment - deleteCoreV1CollectionNamespacedPersistentVolumeClaim - deleteCoreV1CollectionPersistentVolume

- deleteCoreV1Node - deleteCoreV1PersistentVolume - deleteStorageV1CollectionCSINode <del> - deleteStorageV1CollectionStorageClass </del> - deleteStorageV1CollectionVolumeAttachment - deleteStorageV1CSINode <del> - deleteStorageV1StorageClass </del> - deleteStorageV1VolumeAttachment - getInternalApiserverAPIGroup - getResourceAPIGroup - listCoreV1PersistentVolumeClaimForAllNamespaces - listStorageV1CSINode <del> - listStorageV1StorageClass </del> - listStorageV1VolumeAttachment - patchCoreV1NamespacedPersistentVolumeClaim - patchCoreV1NamespacedPersistentVolumeClaimStatus - patchCoreV1PersistentVolume - patchCoreV1PersistentVolumeStatus - patchStorageV1CSINode <del> - patchStorageV1StorageClass </del> - patchStorageV1VolumeAttachment - patchStorageV1VolumeAttachmentStatus - readCoreV1NamespacedPersistentVolumeClaim

- readCoreV1PersistentVolume - readCoreV1PersistentVolumeStatus - readStorageV1CSINode <del> - readStorageV1StorageClass </del> - readStorageV1VolumeAttachment - readStorageV1VolumeAttachmentStatus - replaceCoreV1NamespacedPersistentVolumeClaim

- replaceCoreV1PersistentVolume - replaceCoreV1PersistentVolumeStatus - replaceStorageV1CSINode <del> - replaceStorageV1StorageClass </del> - replaceStorageV1VolumeAttachment - replaceStorageV1VolumeAttachmentStatus
Change:
/kind flake <!-- If this is a flake, please add: /kind flake --/sig storage
The last time I see the flake is in
/assign /sig apimechinery It's broken by a validation webhook with match conditions which is created by
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /assign /sig apimechinery 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
/sig api-machinery
I have raised a pr to fix it. can you help to review it?
/close duplicate of and thanks for the fix PR too.
Closing this issue. <detailsIn response to : /close duplicate of and thanks for the fix PR too. 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
/triage accepted

Discussion:
Rule: admissionregistrationv1.Rule{ APIGroups:   []string{""}, APIVersions: []string{"v1"}, <del> Resources:   []string{"*"}, </del> <ins> Resources:   []string{"configmaps"}, </ins> }, }}, ClientConfig: admissionregistrationv1.WebhookClientConfig{
Change:
[It] [sig-api-machinery] Namespaces [Serial] should apply changes to a namespace status [Conformance] Since Change on the assertions semantics? No response /sig api-machinery /sig testing
/assign This test is critical as it is in the conformance suite
/priority critical-urgent
FYI: The following tests are also failing: master informing master-blocking
It should be resolved by
/triage accepted

Discussion:
}) framework.ExpectNoError(err, "failed to update namespace status %s", ns) gomega.Expect(statusUpdated.Status.Conditions).To(gomega.HaveLen(len(statusUpdated.Status.Conditions)), "updated object should have the applied condition, got %#v", statusUpdated.Status.Conditions) <del> gomega.Expect(statusUpdated.Status.Conditions[len(statusUpdated.Status.Conditions)-1].Type).To(gomega.Equal("StatusUpdate"), "updated object should have the approved condition, got %#v", statusUpdated.Status.Conditions) </del> <ins> gomega.Expect(statusUpdated.Status.Conditions[len(statusUpdated.Status.Conditions)-1].Type).To(gomega.Equal(v1.NamespaceConditionType("StatusUpdate")), "updated object should have the approved condition, got %#v", statusUpdated.Status.Conditions) </ins> gomega.Expect(statusUpdated.Status.Conditions[len(statusUpdated.Status.Conditions)-1].Message).To(gomega.Equal("Updated by an e2e test"), "The Message returned was %v", statusUpdated.Status.Conditions[0].Message) framework.Logf("Status.Condition: %#v", statusUpdated.Status.Conditions[len(statusUpdated.Status.Conditions)-1]) })
Change:
The function in accepts an parameter which it describes as a way to "controller specific flags to be included in the complete set of controller manager flags". However, when the usage string is shown (either via or when parsing options fails), these additional options are not included in the usage string. This was identified via code inspection while trying to figure out what options did in . For e.g. , the output of should include a section corresponding to . This section should in turn list all of . a cloud provider executable that includes additional options, such as the additional options are not shown in the output No response_ n/a (all cloud providers are affected) n/a n/a n/a n/a
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 cloud-provider

Discussion:
cmd.SetUsageFunc(func(cmd *cobra.Command) error { fmt.Fprintf(cmd.OutOrStderr(), usageFmt, cmd.UseLine()) cliflag.PrintSections(cmd.OutOrStderr(), namedFlagSets, cols) <ins> cliflag.PrintSections(cmd.OutOrStderr(), additionalFlags, cols) </ins> return nil }) cmd.SetHelpFunc(func(cmd *cobra.Command, args []string) { fmt.Fprintf(cmd.OutOrStdout(), "%snn"+usageFmt, cmd.Long, cmd.UseLine()) cliflag.PrintSections(cmd.OutOrStdout(), namedFlagSets, cols) <ins> cliflag.PrintSections(cmd.OutOrStdout(), additionalFlags, cols) </ins> }) return cmd
Change:
Seen on the CI here in this specific job The apiserver returns 503 and the [function fails inmediatly] () instead of retrying I expected my fix to retry on those errors, but is clearly not the case I find very hard to understand the logic to retry in this function, can you PTAL and identify the reason why that function is not retrying on these errors?
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 testing
As best I can tell if does in fact return true then that should have worked.
The problem is that this code here isn't actually returning a status error: The status error is embedded inside the new error, but not wrapped. Therefore doesn't find it and returns false -no retries. Fix in

Discussion:
if err != nil { // We may encounter errors here because of a race between the pod readiness and apiserver <del> // proxy. So, we log the error and retry if this occurs. return nil, fmt.Errorf("Controller %s: failed to Get from replica pod %s:n%snPod status:n%s", </del> <ins> // proxy or because of temporary failures. The error gets wrapped for framework.HandleRetry. // Gomega+Ginkgo will handle logging. return nil, fmt.Errorf("controller %s: failed to Get from replica pod %s:n%wnPod status:n%s", </ins> controllerName, pod.Name, <del> format.Object(err, 1), format.Object(pod.Status, 1)) </del> <ins> err, format.Object(pod.Status, 1)) </ins> } responses = append(responses, response{podName: pod.Name, response: string(body)}) }
Change:
Internal job that runs k8s UT with master golang. https://prow.ppc64le- UT is failing when run with golang tip version. Around 24th of August No response This being a negative test scenario, looking at the test log, it seems the failure message from rest client isn't matching the expected in the string at The part of the text that doesn't match is: Expected: Actual: Steps to reproduce: master golang version clone kubernetes/test/e2e/framework/pod test -v -run TestFailureOutput /sig testing
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
/remove-kind failing-test /kind cleanup
is it happening in x86 too? is a golang bug ? there is also another bigger problem
Yes it is happening in x86 too. Yes, it could even be a golang bug too. But thought some upgrades in golang might require modification here in k8s. The above panic error that you pointed out already has an issue
This issue is introduced post addition of https://go- Global level functions are getting wrapped by synthetic init and so is getting changed to in actual traceback. Fix strategy has to be decided to support golang change mentioned above. Tagging others to request more inputs. /cc
^^
I think the output test is too strict: it shouldn't depend on the name given to anonymous functions. On the other hand, it should still ensure that functions like are printed as expected. This can be solved by further transforming the text during - I'll prepare a PR. /assign

Discussion:
out := normalizeLocation(in) out = stripTimes(out) out = stripAddresses(out) <ins> out = normalizeInitFunctions(out) </ins> if expected.NormalizeOutput != nil { out = expected.NormalizeOutput(out) }

out = klogPrefix.ReplaceAllString(out, "<klog> ") return out } <ins> var initFunc = regexp.MustCompile(`(init.+func|glob.+func)`) // normalizeInitFunctions maps both init.func (used by Go >= 1.22) and // glob..func (used by Go < 1.22) to <init.func>. func normalizeInitFunctions(in string) string { out := initFunc.ReplaceAllString(in, "<init.func>") return out } </ins>
Change:
FAIL: TestWebSocketClientHeartbeatSucceeds also flake in ci-kubernetes-unit use of closed network connection /cc /sig api-machinery network cli
/cc /triage accepted
seems it got better since
The new flake in this test is like I also see the failure in some PR: for instance.
yeah, it is racing somewhere , at least we have a different symptom now
/help someone want a great challenge and make a very useful contribution?
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help 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
something odd is with the test, the panic is because it logs on the goroutine, but I'm not completely sure the test is working as expected
my apologies, I found the problem and I'm submitting a patch /assign /unassign you can help me with the review if you want

Discussion:
for { _, _, err := conn.ReadMessage() if err != nil { <del> t.Logf("server err reading message: %v", err) return </del> <ins> break </ins> } } }))

return pongHandler(msg) }) go heartbeat.start() <ins> var wg sync.WaitGroup wg.Add(1) </ins> go func() { <ins> defer wg.Done() </ins> for { _, _, err := client.ReadMessage() if err != nil {

close(heartbeat.closer) t.Errorf("unexpected heartbeat timeout") } <ins> wg.Wait() </ins> } func TestWebSocketClient_StreamsAndExpectedErrors(t *testing.T) {