jiebi/CodeConvo huggingface dataset:
Change:
master-blocking: integration-master- This has been occasionally flaking for some time. Recent Failures: Another leak was fixed at /sig api-machinery /sig testing
/retitle [Flaking Test] integration-master (goroutine leak detection)
Some server is not stopping gracefully on that test
Similar reason:
Its either not terminating gracefully or there is a request that isn't being being served in a timely manner, because I also see a bunch of goroutines waiting on the netpoller.
/triage accepted (for SIG api-machinery)
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /triage accepted (for SIG api-machinery) 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 don't think this would be a release blocker, still can you confirm whether this would block the upcoming alpha 1 release cut?
Another failure:
Hey , The deadline for the alpha 1 release cut has been delayed to Monday, June 10 and we are still waiting for confirmation of this issue. Do you think this will be a release blocker?
/assign
/assign
integration test flake, we believe this PR fixes it: I'm not marking this fixed because it also mentions a integration test flake.

Discussion:
// Both names occurred in practice. goleak.IgnoreTopFunction("k8s.io/kubernetes/vendor/gopkg.in/natefinch/lumberjack%2ev2.(*Logger).millRun"), goleak.IgnoreTopFunction("gopkg.in/natefinch/lumberjack%2ev2.(*Logger).millRun"), <ins> // If there is an error during connection shutdown, SPDY keeps a // goroutine around for ten minutes, which gets reported as a leak // (the goroutine is cleaned up after the ten minutes). // // https://github.com/kubernetes/kubernetes/blob/master/vendor/github.com/moby/spdystream/connection.go#L732-L744 // // Ignore this reported leak. goleak.IgnoreTopFunction("github.com/moby/spdystream.(*Connection).shutdown"), </ins> ) stop, err := startEtcd(nil)
Change:
Hello k8s folks: This code here: is making a call to the function , which is documented as not maintaining the Go 1 compatibility guarantee. Here is the header comment for MainStart: Filing this issue to let you know that in the upcoming Go release (1.23) the signature of MainStart is indeed changing; there is a new method on the testDeps interface. If you could please add this new method to your dummy testDeps interface (as in the previous patch that would be great. Thanks. from the golang team. N/A N/A No response <details</details<detailsN/A </details<details</details<details</details<details</details<details</details
Closing this issue. <detailsIn response to : a better place to ask would be on the support channels. please see: /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Reopened this issue. <detailsIn response to : /reopen </details
/sig release
/assign mauri870
/triage accepted
/sig testing
many thanks for the report. release folks, let's start the go1.23 tracking issue we can link this to as a PR that will need picking to release branches to make them ready for eventual update to 1.23
cc

Discussion:
//nolint:unused // U1000 see comment above, we know it's unused normally. func (fakeTestDeps) SnapshotCoverage() {} <ins> //nolint:unused // U1000 see comment above, we know it's unused normally. func (fakeTestDeps) InitRuntimeCoverage() (mode string, tearDown func(string, string) (string, error), snapcov func() float64) { return "", nil, nil } </ins>
Change:
tainteviction NA 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
The panic is in the event watcher, you have landed several changes recently that are most probably related, can you PTAL? /sig instrumentation
ok, so the problem is this The watcher fails to be created but the goroutine keeps going and tries to get a channel from it /assign
That problem has already been there before the recent changes: When constructing the watch fails, that code needs to return instead of spawning the goroutine. I think this is okay: The indicates that the occurs after the test has completed. Before the recent changes, creating the watch would have succeeded and the test would have permanently leaked the goroutines. In that sense, the recent changes work as intended.
ok, so this just uncovered an existing bug, those are the positive news
I don't know if we'll translate the problem to other layer, as will return a nil , it seems StartEventWatcher has to also return an error?
I'm adding -
Because of , this shouldn't occur in production.

Discussion:
func (e *eventBroadcasterImpl) StartEventWatcher(eventHandler func(*v1.Event)) watch.Interface { watcher, err := e.Watch() if err != nil { <ins> // This function traditionally returns no error even though it can fail. // Instead, it logs the error and returns an empty watch. The empty // watch ensures that callers don't crash when calling Stop. </ins> klog.FromContext(e.cancelationCtx).Error(err, "Unable start event watcher (will not retry!)") <ins> return watch.NewEmptyWatch() </ins> } go func() { defer utilruntime.HandleCrash()
Change:
sig-release-master-blocking ci-kubernetes-unit 05/30/2024 19:25 IST Prow Logs: Triage: No response /sig
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig storage
/sig api-machinery
/cc This started last week, but it seems to be fairly rare, so might be a consequence of something a bit earlier. The value of "2" suggests that it's happening on the first event, and my brain goes towards: - will you be able to take a look at it?
sure, I will have a look. /assign
We chatted with about that offline and it seems like a real correctness issue. Regression indeed introduced by We have a race with setting RV in watchcache and incoming events. The current explanation is: initializeds with RV=N event comes with RV=N+1 [but wasn't yet dispatched] polling introduced in that PR catches RV=N+1 then the event (with RV=N+1) is received
So it is a release blocker, then? (Upcoming alpha 1 release cut scheduled for tomorrow)
I don't know what the release policy is but we might have a potential fix for this issue.
This is a real correctness bug introduced 2 weeks ago. I'm not sure what's our policy is for alpha releases, but it sounds like a potential blocker to me.
The fix for it is already approved.

Discussion:
// The first successful sync with the underlying store. // The cache must wait until this first sync is completed to be deemed ready. // Since we cannot send a bookmark when the lastProcessedResourceVersion is 0, <del> // we poll aggressively for the first RV before entering the dispatch loop. </del> <ins> // we poll aggressively for the first list RV before entering the dispatch loop. </ins> lastProcessedResourceVersion := uint64(0) if err := wait.PollUntilContextCancel(wait.ContextForChannel(c.stopCh), 10*time.Millisecond, true, func(_ context.Context) (bool, error) { <del> if rv := c.watchCache.getResourceVersion(); rv != 0 { </del> <ins> if rv := c.watchCache.getListResourceVersion(); rv != 0 { </ins> lastProcessedResourceVersion = rv return true, nil }

return nil } <del> func (w *watchCache) getResourceVersion() uint64 { </del> <ins> func (w *watchCache) getListResourceVersion() uint64 { </ins> w.RLock() defer w.RUnlock() <del> return w.resourceVersion </del> <ins> return w.listResourceVersion </ins> } func (w *watchCache) currentCapacity() int {
Change:
We're trying to upgrade to () and found the issue on executing (). The problem is that on () missed dependency that not allow to install () No error To reproduce the same what happening on , just execute this command on code-generator folder: I think it's happens after this commit <details</details<details</details<details</details<details</details<details</details<details</details
/cc
/assign
/sig api-machinery
I was able to reproduce, but just because I had an older version of kube-openapi in my GOPATH. Using the prefix in the command fixed it. I think line needs to be
Yeah, with works for me too.
Either that or we pin to a more recent commit, for example . For some reason if you ommit the version it is using a from Feb 27.
thanks for investigating. Question, if we use would this not cause problems in the future if we try to build a release branch from the past? Maybe this is not a big deal. OTOH if we hardcode a tag, it may create maintenance costs. I'm wondering if there is a better way, say to version and use the corresponding tag, say ?
Using tags would be a way to have more reproducible builds, they still need to be tagged from time to time tho. That is still better than using or micro managing commit revisions.
Thanks and for the research. Is either of you thinking on submitting a fix for this? Thanks!
I can do it.
Thanks! /assign mbobrovskyi
Yes, please don't use Generally instead we'd control the version of a tool in the hack/tools module and install it from there (see e.g.
This allows us to also gain for the package while not polluting the main module with dev-only dependencies.
Not sure if we need to make another Because it's not just a dev-only dependency. I propose to add it to of code-generator.
This is about semversioning
/triage accepted

Discussion:
) require ( <ins> github.com/emicklei/go-restful/v3 v3.11.0 // indirect </ins> github.com/go-logr/logr v1.4.1 // indirect github.com/go-openapi/jsonpointer v0.19.6 // indirect github.com/go-openapi/jsonreference v0.20.2 // indirect

github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc h1:U9qPSI2PIWSS1VwoXQT9A3Wy9MM3WgvqSxFWenqJduM= github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= <del> github.com/emicklei/go-restful/v3 v3.8.0/go.mod h1:6n3XBCmQQb25CM2LCACGz8ukIrRry+4bhvbpWn3mrbc= </del> <ins> github.com/emicklei/go-restful/v3 v3.11.0 h1:rAQeMHw1c7zTmncogyy8VvRZwtkmkZ4FxERmMY4rD+g= github.com/emicklei/go-restful/v3 v3.11.0/go.mod h1:6n3XBCmQQb25CM2LCACGz8ukIrRry+4bhvbpWn3mrbc= </ins> github.com/fxamacker/cbor/v2 v2.7.0-beta h1:m5bO941uTVpSms26QjzEJxUZaC3S/h1pSJexBCu4wAA= github.com/fxamacker/cbor/v2 v2.7.0-beta/go.mod h1:pxXPTn3joSm21Gbwsv0w9OSA2y1HFR9qXEeXQVeNoDQ= github.com/go-logr/logr v1.4.1 h1:pKouT5E8xu9zeFC39JXRDukb6JFQPXM5p5I91188VAQ=

_ "k8s.io/code-generator/cmd/informer-gen" _ "k8s.io/code-generator/cmd/lister-gen" _ "k8s.io/code-generator/cmd/register-gen" <ins> _ "k8s.io/kube-openapi/cmd/openapi-gen" </ins> )
Change:
The err is already checked on line 84, so it will always be nil On line 107, the check is redundant
That is indeed redundant. It seems like someone forgot to remove after a refactor but It was this way in
Feel free to send a pull request by following Thanks.
Thanks! I am wondering whether it is necessary to check ip address returned by calling or is As in But I don't find the overflowed cases yet.
/sig network
/assign DrAuYueng
Hmmm, in theory yes, since .Next() and .Prev() can return an empty netip.Addr. In practice, they probably never overflow in this particular case. Adding a check for .IsValid() for both Prev and Next would not hurt. I don't expect the path of !ip.IsValid() to be ever taken in these cases, but if they do then that is a bug and it should propagate an error.
/triage accepted

Discussion:
// of having to do conversions with IP addresses. // Don't allocate the network's ".0" address. ipFirst := prefix.Masked().Addr().Next() <del> if err != nil { return nil, err } </del> // Use the broadcast address as last address for IPv6 ipLast, err := broadcastAddress(prefix) if err != nil {
Change:
pull-kubernetes-node-e2e-containerd ci-cos-containerd-node-e2e ci-kubernetes-e2e-node-canary Containers should use the image defaults if command and args are blank At least 7th June: ! No response /sig node
/cc This also flake in
/triage accepted /assign
/priority backlog
couple more flakes
Opened up to see if we can resolve this.

Discussion:
import ( "context" <ins> "time" </ins> "github.com/onsi/gomega"

// The agnhost's image default entrypoint / args are: "/agnhost pause" // which will print out "Paused". <del> gomega.Eventually(ctx, pollLogs, 3, framework.Poll).Should(gomega.ContainSubstring("Paused")) </del> <ins> gomega.Eventually(ctx, pollLogs, time.Minute, framework.Poll).Should(gomega.ContainSubstring("Paused")) </ins> }) /*
Change:
sig-testing-kind: cloud-provider-kind (IPv6), master (dev) [non-serial] (IPv6),%20master%20(dev)%20%5Bnon-serial%5D No response /sig network 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
/cc
Checking It fails to get a value from the healtcheck nodeport however, it seems it is listening there /help /sig network you were recently working on this area of healthcecks and ip families, does this ring a bell? This should be easy to reproduce using kind and cloud-provider-kind if someone wants to help
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 : Checking however, it seems it is listening there /sig network 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
it is not a flake, curl from test container fails because of bad url formatting (for ipv6 hosts).
embarrassing, now I can see it was obvious

Discussion:
// GetHTTPCodeFromTestContainer executes a curl via kubectl exec in a test container and returns the status code. func (config *NetworkingTestConfig) GetHTTPCodeFromTestContainer(ctx context.Context, path, targetIP string, targetPort int) (int, error) { <del> cmd := fmt.Sprintf("curl -g -q -s -o /dev/null -w %%{http_code} http://%s:%d%s", targetIP, targetPort, </del> <ins> cmd := fmt.Sprintf("curl -g -q -s -o /dev/null -w %%{http_code} http://%s%s", net.JoinHostPort(targetIP, strconv.Itoa(targetPort)), </ins> path) stdout, stderr, err := e2epod.ExecShellInPodWithFullOutput(ctx, config.f, config.TestContainerPod.Name, cmd) // We only care about the status code reported by curl,
Change:
master-blocking: gce-ubuntu-master-containerd No response /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

Discussion:
rs.Labels["name"] = rsName initialDelaySeconds := framework.PodStartTimeout.Seconds() + 30 if tc.podsShouldBecomeReadyFirst { <del> initialDelaySeconds = 0 </del> <ins> initialDelaySeconds = 20 </ins> } rs.Spec.Template.Spec.Containers[0].ReadinessProbe = &v1.Probe{ ProbeHandler: v1.ProbeHandler{

Namespace: ns, }, } <ins> // New pods can be created between the evictions by a replica set controller. // This can affect the PDB, and pods could potentially be evicted that shouldn't be. // To prevent this, there should always be a sufficient pod readiness delay (see initialDelaySeconds). </ins> err = cs.CoreV1().Pods(ns).EvictV1(ctx, e) if err == nil { evictedPods.Insert(pod.Name)
Change:
When the FailureTarget=False condition is manually, then the Job terminates. The condition should be ignored by the Job controller. the like this: the following script to repro: Issue: the Job gets terminated with the status like this: No response <details</details<detailsKind </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/cc
/assign Thanks!
/sig apps

Discussion:
// Given that the Job already has the SuccessCriteriaMet condition, the termination condition already had confirmed in another cycle. // So, the job-controller evaluates the podFailurePolicy only when the Job doesn't have the SuccessCriteriaMet condition. if jobCtx.finishedCondition == nil && feature.DefaultFeatureGate.Enabled(features.JobPodFailurePolicy) { <del> if failureTargetCondition := findConditionByType(job.Status.Conditions, batch.JobFailureTarget); failureTargetCondition != nil { </del> <ins> failureTargetCondition := findConditionByType(job.Status.Conditions, batch.JobFailureTarget) if failureTargetCondition != nil && failureTargetCondition.Status == v1.ConditionTrue { </ins> jobCtx.finishedCondition = newFailedConditionForFailureTarget(failureTargetCondition, jm.clock.Now()) } else if failJobMessage := getFailJobMessage(&job, pods); failJobMessage != nil { // Prepare the interim FailureTarget condition to record the failure message before the finalizers (allowing removal of the pods) are removed.

} type jobInitialStatus struct { <del> active    int succeed   int failed    int startTime *time.Time </del> <ins> active     int succeed    int failed     int startTime  *time.Time conditions []batch.JobCondition </ins> } func TestControllerSyncJob(t *testing.T) {

podIndexLabelDisabled:  true, expectedReady:          ptr.To[int32](0), }, <ins> "FailureTarget=False condition added manually is ignored": { jobPodFailurePolicy: true, parallelism:         1, completions:         1, activePods:          1, readyPods:           1, initialStatus: &jobInitialStatus{ active: 1, startTime: func() *time.Time { now := time.Now() return &now }(), conditions: []batch.JobCondition{ { Type:    batch.JobFailureTarget, Status:  v1.ConditionFalse, Reason:  "ConditionAddedManually", Message: "Testing", }, }, }, expectedActive: 1, expectedReady:  ptr.To[int32](1), expectedConditions: []batch.JobCondition{ { Type:    batch.JobFailureTarget, Status:  v1.ConditionFalse, Reason:  "ConditionAddedManually", Message: "Testing", }, }, }, </ins> } for name, tc := range testCases {

startTime := metav1.NewTime(*tc.initialStatus.startTime) job.Status.StartTime = &startTime } <ins> job.Status.Conditions = append(job.Status.Conditions, tc.initialStatus.conditions...) </ins> } key, err := controller.KeyFunc(job)
Change:
Deployed sample-apiserver into a kind cluster following the instructions in Checked wardle-server pod logs, found the following error: No such errors. Deployed sample-apiserver into a kind cluster following the instructions in <details</detailsKIND
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
/assign Will submit a fix shortly.

Discussion:
resources: ["namespaces"] verbs: ["get", "watch", "list"] - apiGroups: ["admissionregistration.k8s.io"] <del> resources: ["mutatingwebhookconfigurations", "validatingwebhookconfigurations"] </del> <ins> resources: ["mutatingwebhookconfigurations", "validatingwebhookconfigurations", "validatingadmissionpolicies", "validatingadmissionpolicybindings"] </ins> verbs: ["get", "watch", "list"] - apiGroups: ["flowcontrol.apiserver.k8s.io"] resources: ['prioritylevelconfigurations', 'flowschemas']
Change:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig cloud-provider-gcp testing
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : ### Failure cluster /kind failing-test /sig cloud-provider-gcp testing 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 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
Take as an example. In log, we can see the waiting for a node which is not deleted. test--minion-group-99m3 was the first node and not deleted in the node lease e2e test test--minion-group-dhj9 is the node that was removed in the e2e test.
/cc

Discussion:
var deletedNodeName string for _, originalNode := range originalNodes.Items { originalNodeName := originalNode.ObjectMeta.Name <ins> var found bool </ins> for _, targetNode := range targetNodes.Items { if originalNodeName == targetNode.ObjectMeta.Name { <del> continue </del> <ins> found = true break </ins> } } <del> deletedNodeName = originalNodeName break </del> <ins> if !found { deletedNodeName = originalNodeName break } </ins> } gomega.Expect(deletedNodeName).NotTo(gomega.BeEmpty()) gomega.Eventually(ctx, func() error {
Change:
master-informing: gce-cos-master-slow Failure cluster No response /sig network
checking why has the context deadline exceeded?
I see, is because of this /assign sending a fix for this
/triage accepted

Discussion:
e2eservice.TestReachableHTTP(ctx, ingress, svcPort, loadBalancerLagTimeout) ginkgo.By("checking reachability from pods when LoadBalancerSourceRanges is unset") <del> // We can use timeout 0 here since we know from above that the service is // already running (and we aren't waiting for changes to it to propagate). checkReachabilityFromPod(ctx, true, 0, namespace, acceptPod.Name, ingress) checkReachabilityFromPod(ctx, true, 0, namespace, dropPod.Name, ingress) </del> <ins> // There are different propagation delay for the APIs for different nodes, so it tries // a few times, despite previously it was confirmed that the Service was reachable. checkReachabilityFromPod(ctx, true, e2eservice.KubeProxyEndpointLagTimeout, namespace, acceptPod.Name, ingress) checkReachabilityFromPod(ctx, true, e2eservice.KubeProxyEndpointLagTimeout, namespace, dropPod.Name, ingress) </ins> // Create source ranges that allow acceptPod but not dropPod or // cluster-external sources. We assume that the LBSR rules will either see