jiebi/CodeConvo huggingface dataset:
Change:
has an outdated code comment that refers to the func . That function was removed in Can this comment be updated what should be used instead. TIA /kind documentation
/sig api-machinery
Hi! thank you for your finding! Would you send us a PR and we will review it? it's the most effective way of fixing it! Thank you in advance!
/assign
/assign /unassign Akhilesh2412
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/remove-lifecycle stale

Discussion:
// Until wraps the watcherClient's watch function with RetryWatcher making sure that watcher gets restarted in case of errors. // The initialResourceVersion will be given to watch method when first called. It shall not be "" or "0" <del> // given the underlying WATCH call issues (#74022). If you want the initial list ("", "0") done for you use ListWatchUntil instead. </del> <ins> // given the underlying WATCH call issues (#74022). </ins> // Remaining behaviour is identical to function UntilWithoutRetry. (See above.) // Until can deal with API timeouts and lost connections. // It guarantees you to see all events and in the order they happened.
Change:
One use-case of is to wait for a lot of resources that you have just deleted. Unfortunately, this workflow is racy because will fail when encountering a resource that doesn't exist (yes, it's probably already gone). I suspect we should just consider 404 resources to be already gone and integrate that condition as part of the normal flow. /sig cli /kind bug
/assign
Duplicate of ?
yes, I tried to add in in But that PR seems not complete.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
The PR merged, I think we're good now!

Discussion:
return err } visitor := o.ResourceFinder.Do() <del> if visitor, ok := visitor.(*resource.Result); ok && strings.ToLower(o.ForCondition) == "delete" { </del> <ins> isForDelete := strings.ToLower(o.ForCondition) == "delete" if visitor, ok := visitor.(*resource.Result); ok && isForDelete { </ins> visitor.IgnoreErrors(apierrors.IsNotFound) }

if err != nil { return err } <del> if visitCount == 0 { </del> <ins> if visitCount == 0 && !isForDelete { </ins> return errNoMatchingResources } return err

listMapping := map[schema.GroupVersionResource]string{ {Group: "group", Version: "version", Resource: "theresource"}: "TheKindList", } <del> infos := []*resource.Info{ { Mapping: &meta.RESTMapping{ Resource: schema.GroupVersionResource{Group: "group", Version: "version", Resource: "theresource"}, }, Name:      "name-foo", Namespace: "ns-foo", }, } </del> <ins> infos := []*resource.Info{} </ins> fakeClient := dynamicfakeclient.NewSimpleDynamicClientWithCustomListKinds(scheme, listMapping) o := &WaitOptions{

} }) }) <ins> ginkgo.Describe("kubectl wait", func() { ginkgo.It("should ignore not found error with --for=delete", func() { ginkgo.By("calling kubectl wait --for=delete") framework.RunKubectlOrDie(ns, "wait", "--for=delete", "pod/doesnotexist") framework.RunKubectlOrDie(ns, "wait", "--for=delete", "pod", "--selector=app.kubernetes.io/name=noexist") }) }) </ins> }) // Checks whether the output split by line contains the required elements.
Change:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: pull-kubernetes-e2e-gce (5% of runs) pull-kubernetes-e2e-kind-ipv6 pull-kubernetes-e2e-gce-ubuntu-containerd Which test(s) are flaking: This is the flakiest test in the e2e job according to Testgrid link: Reason for failure: Anything else we need to know:
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
merged 2 weeks ago in
/assign
potential mitigation in
To track down the test flaking there was some great feedback in by and was created as a potential fix based on that feedback /cc

Discussion:
ginkgo.It("should delete a collection of pods", func() { podTestNames := []string{"test-pod-1", "test-pod-2", "test-pod-3"} <ins> zero := int64(0) </ins> ginkgo.By("Create set of pods") // create a set of pods in test namespace for _, podTestName := range podTestNames {

"type": "Testing"}, }, Spec: v1.PodSpec{ <ins> TerminationGracePeriodSeconds: &zero, </ins> Containers: []v1.Container{{ Image: imageutils.GetE2EImage(imageutils.Agnhost), Name:  "token-test",

framework.ExpectNoError(err, "3 pods not found") // delete Collection of pods with a label in the current namespace <del> err = f.ClientSet.CoreV1().Pods(f.Namespace.Name).DeleteCollection(context.TODO(), metav1.DeleteOptions{}, metav1.ListOptions{ </del> <ins> err = f.ClientSet.CoreV1().Pods(f.Namespace.Name).DeleteCollection(context.TODO(), metav1.DeleteOptions{GracePeriodSeconds: &zero}, metav1.ListOptions{ </ins> LabelSelector: "type=Testing"}) framework.ExpectNoError(err, "failed to delete collection of pods")
Change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Testing API Priority and Fairness, I issued this command in a rather idle cluster: and I got this result: That is, a list of one request with no information of any sort. That comes from , which invents one phantom request for each priority level that is exempt. We do not want or need a phantom request; is for listing requests in queues. What you expected to happen: I expected to get only queued requests. How to reproduce it (as minimally and precisely as possible): As shown above, with API Priority and Fairness enabled. Anything else we need to know?: Environment: Kubernetes version (use ): this is in Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/cc /cc /cc

Discussion:
endLine(tabWriter) for _, plState := range cfgCtlr.priorityLevelStates { if plState.queues == nil { <del> tabPrint(tabWriter, row( plState.pl.Name, // 1 "<none>",        // 2 "<none>",        // 3 "<none>",        // 4 "<none>",        // 5 "<none>",        // 6 )) if includeRequestDetails { continueLine(tabWriter) tabPrint(tabWriter, row( "<none>", // 7 "<none>", // 8 "<none>", // 9 "<none>", // 10 "<none>", // 11 "<none>", // 12 "<none>", // 13 "<none>", // 14 )) } endLine(tabWriter) </del> continue } queueSetDigest := plState.queues.Dump(includeRequestDetails)
Change:
seen in the PR updating to go1.15, but this unit test should not be flaky /assign
was the flaky run
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
can reproduce locally with:
looks like toCreateByAddrType is a map which doesn't have a defined iteration order, so the address family order of toUpdate is not well-defined
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍

Discussion:
package endpointslicemirroring import ( <ins> "sort" </ins> "testing" discovery "k8s.io/api/discovery/v1beta1"

}, expectedSlices: &slicesByAction{ toUpdate: []*discovery.EndpointSlice{ <del> simpleEndpointSlice("baz", "10.2.3.4", discovery.AddressTypeIPv4), </del> simpleEndpointSlice("bar", "10.1.2.3", discovery.AddressTypeIPv4), <ins> simpleEndpointSlice("baz", "10.2.3.4", discovery.AddressTypeIPv4), </ins> }, }, }, {

for _, tc := range testCases { t.Run(tc.testName, func(t *testing.T) { <del> recycleSlices(tc.startingSlices) </del> <ins> startingSlices := tc.startingSlices recycleSlices(startingSlices) unorderedSlices := [][]*discovery.EndpointSlice{startingSlices.toCreate, startingSlices.toUpdate, startingSlices.toDelete} for _, actual := range unorderedSlices { sort.Slice(actual, func(i, j int) bool { return actual[i].Name < actual[j].Name }) } </ins> <del> expectEqualSlices(t, tc.startingSlices.toCreate, tc.expectedSlices.toCreate) expectEqualSlices(t, tc.startingSlices.toUpdate, tc.expectedSlices.toUpdate) expectEqualSlices(t, tc.startingSlices.toDelete, tc.expectedSlices.toDelete) </del> <ins> expectEqualSlices(t, startingSlices.toCreate, tc.expectedSlices.toCreate) expectEqualSlices(t, startingSlices.toUpdate, tc.expectedSlices.toUpdate) expectEqualSlices(t, startingSlices.toDelete, tc.expectedSlices.toDelete) </ins> }) } }
Change:
Which jobs are flaking: ci-kubernetes-integration-master Which test(s) are flaking: ci-kubernetes-integration-master Testgrid link: Reason for failure: Anything else we need to know: 5 seconds seems aggressive for a controller test run in parallel with other tests ... unless this is testing performance-oriented changes, wait.ForeverTestTimeout seems more appropriate
/milestone v1.19 /assign /sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Thanks for filing this! I've opened to fix this. /remove-triage unresolved
still saw one occurrence at
in presubmits: races the endpoints controller by creating the service object first, then the endpoints object, and not tolerating an AlreadyExists error because the controller created the endpoints object first: reproducible with:
For the failures, I don't see any evidence the endpointslicemirroring controller is syncing items Failures: There are log lines from and in the test output, but no log lines from indicating an item was ever synced Locally: scanning junit stdout artifacts from a run: and a run:
while rummaging around in the endpointslice controllers' startup code, I noticed the main endpointslice controller doesn't wait for endpointslices and nodes to be synced before starting. I would have expected the following to avoid churn at controller startup: If you agree, that seems like an important thing to fix separately and pick to 1.16-1.18
ok, fixes for known flakes are merged, will watch these grids for failures after merged:
cc
seen again in
Thanks to for showing me how to stress test this! This ended up failing once every ~3,000 runs for me. Fortunately I think the problem is actually pretty easy to understand now. The EndpointSliceMirroring controller does not have any event handlers for Services. The logic for an Endpoints resource checks a number of things including if a Service exists for the Endpoints resource. In these test failures the Service is not in the cache when that check is run. Because there are no further changes to the Endpoints resource and because we don't have any event handlers for Service changes/additions, an EndpointSlice is never created. I've got a full day today but hope to be able to get a fix in for this early next week.
Thanks for tracking this down. Discussed offline that we don't really need to check the service's existence, we can mirror the endpointslice, associate it with the endpoints object, and garbage collection will do the right thing if the endpoints object is removed. This is important to include a fix for to avoid a regression (however obscure) in handling of custom endpoints objects.

Discussion:
} } <del> err = wait.PollImmediate(1*time.Second, 5*time.Second, func() (bool, error) { </del> <ins> err = wait.PollImmediate(1*time.Second, wait.ForeverTestTimeout, func() (bool, error) { </ins> lSelector := discovery.LabelServiceName + "=" + resourceName esList, err := client.DiscoveryV1beta1().EndpointSlices(ns.Name).List(context.TODO(), metav1.ListOptions{LabelSelector: lSelector}) if err != nil {
Change:
Which jobs are failing: gce-master-scale-correctness Which test(s) are failing: all - whole test set OOMed Since when has it been failing: 2020-07-28 Testgrid link: https://k8s- Reason for failure: test pod OOMed after setting 16Gi memory limit Anything else we need to know:
/sig scalability /assign
/lgtm /approve
Not this window :) it was supposed to be for kubernetes/test-infra
Looks fixed?
Yeah - last run didn't OOM, so I think we can close this one.
Another 2 runs OOMed: /reopen
Reopened this issue. <detailsIn response to : Another 2 runs OOMed: </details
That seems really ridiculous to me. The fact that our performance tests can work with 16GB makes it super strange that simple correctness tests require 32GB+...
^^
/reopen Leaving discussion open
Reopened this issue. <detailsIn response to : /reopen Leaving discussion open </details
64Gi is too much, we need to find a proper limit: /cc
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Testgrid is green

Discussion:
Interval:       interval, Timeout:        timeout, CleanupPolicy:  updateCleanupPolicy, <del> MaxUnavailable: intstr.FromInt(0), </del> <ins> MaxUnavailable: intstr.FromInt(1), </ins> MaxSurge:       intstr.FromInt(1), } if rollback {
Change:
Background: We recently introduced Guaranteed Pod QOS on jobs running in GCP project (). Introducing limits on jobs naturally started causing some failures, one of which was (). The original memory limit of caused the pod to be unscheduleable, so it was bumped down to () at which point the pod became scheduleable and the job ran successfully (). At that point, after observing metrics, I mistakenly concluded that this was much higher than needed and suggested bumping down again (). This caused the job to continue to run, but to fail on and sometimes . was recently refactored to not depend on GOPATH (). This was a fairly significant change so I looked at the metrics before and after the rewrite was merged. (June 25th) ! (June 27th) ! Memory usage nearly double for post-merge, which appears to be directly related to the rewrite given that on other branches remained relatively constant. This can be affirmed further by the fact that and are failing with the new resource limits, while older release branches are not. I can see a few options for how we may be able to remedy this issue in the short term: Revert the rewrite to get back to lower (yet still very high) memory usage Separate into a separate job to not reduce signal on the rest of Bump memory limits back up to to get this running successfully again for now I plan to look into fixing up but think it would be a good idea to take one of the directions mentioned above if this cannot be remedied quickly. /priority critical-urgent /sig testing /cc
latest run is green
hmm

Discussion:
platforms  = flag.String("platform", "", "comma-separated list of platforms to typecheck") timings    = flag.Bool("time", false, "output times taken for each phase") defuses    = flag.Bool("defuse", false, "output defs/uses") <del> serial     = flag.Bool("serial", false, "don't type check platforms in parallel") </del> <ins> serial     = flag.Bool("serial", false, "don't type check platforms in parallel (equivalent to --parallel=1)") parallel   = flag.Int("parallel", 4, "limits how many platforms can be checked in parallel. 0 means no limit.") </ins> skipTest   = flag.Bool("skip-test", false, "don't type check test code") tags       = flag.String("tags", "", "comma-separated list of build tags to apply in addition to go's defaults") ignoreDirs = flag.String("ignore-dirs", "", "comma-separated list of directories to ignore in addition to the default hardcoded list including staging, vendor, and hidden dirs")

var wg sync.WaitGroup var failMu sync.Mutex failed := false <ins> if *serial { *parallel = 1 } else if *parallel == 0 { *parallel = len(plats) } throttle := make(chan int, *parallel) </ins> for _, plat := range plats { wg.Add(1) <del> fn := func(plat string) { </del> <ins> go func(plat string) { // block until there's room for this task throttle <- 1 defer func() { // indicate this task is done <-throttle }() </ins> f := false serialFprintf(os.Stdout, "type-checking %sn", plat) errors, err := c.verify(plat)

failed = failed || f failMu.Unlock() wg.Done() <del> } if *serial { fn(plat) } else { go fn(plat) } </del> <ins> }(plat) </ins> } wg.Wait() if failed {
Change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: pull-kubernetes-verify Which test(s) are failing: publishing-bot Since when has it been failing: 07-31 12:23 PDT Testgrid link: Reason for failure: missing pyyaml module Anything else we need to know: Running case: verify.publishing-bot +++ working dir: +++ command: python "hack/make-rules/../../hack/verify-publishing-" Please install missing pyyaml module and re-run hack/make-rules/../../hack/verify-publishing- +++ exit code: 1 +++ error: 1
/sig testing
due to python3 bump in test-infra kubekins; being reverted in
Resolved by test-infra revert

Discussion:
ret=0 run-checks "${KUBE_ROOT}/hack/verify-*.sh" bash <del> run-checks "${KUBE_ROOT}/hack/verify-*.py" python </del> <ins> run-checks "${KUBE_ROOT}/hack/verify-*.py" python3 </ins> missing-target-checks if [[ ${ret} -eq 1 ]]; then
Change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: When use client-go to build the client, we implement the event handler for some k8s resourses. Sometime it will panic (maybe cause by the unexpected nil pointer bug), the process will not crash after panic. What you expected to happen: When we use event handler with informer in client-go, sometime it will panic in handler, we expect the process will crash. How to reproduce it (as minimally and precisely as possible): I run process which just panic simpliy in an event handler , use to produce the coredump, and use to check the call stack. The sample code I run is: The call stack of paniced goroutine: We can see the panic was called at frame 16 , and was catched by at 10. It printed the call stack in and panic again. The defer func was call at frame 8, it's (at 5). Panic was blocked at here. Finally, this goroutine was scheduled to , would not exit or crash the whole process. The go code in is : Environment: Kubernetes version (use ):OS (e.g: ):Kernel (e.g. ):
/sig api-machinery
Thanks for finding this! Personally I think any lines of the form are a bug waiting to happen, and in all the cases introduced by are unnecessary - we can simply call at the end.
/assign
Your fix looks better. I think using is easy to make mistakes . It not only defers the execution of a function, but also has some side effects ...

Discussion:
c.reflectorMutex.Unlock() var wg wait.Group <del> defer wg.Wait() </del> wg.StartWithChannel(stopCh, r.Run) wait.Until(c.processLoop, time.Second, stopCh) <ins> wg.Wait() </ins> } // Returns true once this controller has completed an initial resource listing

testDoneWG.Wait() close(stop) } <ins> func TestPanicPropagated(t *testing.T) { // source simulates an apiserver object endpoint. source := fcache.NewFakeControllerSource() // Make a controller that just panic if the AddFunc is called. _, controller := NewInformer( source, &v1.Pod{}, time.Millisecond*100, ResourceEventHandlerFuncs{ AddFunc: func(obj interface{}) { // Create a panic. panic("Just panic.") }, }, ) // Run the controller and run it until we close stop. stop := make(chan struct{}) defer close(stop) propagated := make(chan interface{}) go func() { defer func() { if r := recover(); r != nil { propagated <- r } }() controller.Run(stop) }() // Let's add a object to the source. It will trigger a panic. source.Add(&v1.Pod{ObjectMeta: metav1.ObjectMeta{Name: "test"}}) // Check if the panic propagated up. select { case p := <-propagated: if p == "Just panic." { t.Logf("Test Passed") } else { t.Errorf("unrecognized panic in controller run: %v", p) } case <-time.After(wait.ForeverTestTimeout): t.Errorf("timeout: the panic failed to propagate from the controller run method!") } } </ins>
Change:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: Which test(s) are flaking: Testgrid link: Reason for failure: Anything else we need to know: /sig cli /cc /milestone v1.20 /prority important-soon
after creating the CRD, before applying the CR, kubectl should wait until includes :
/assign
/assign is this issue related to ?
no, this is simply kubectl trying to apply a CR before the server has made the API available at all
Got it! and I have filed to address this issue.
Still happening:
still happening: looks like the root cause is not related to CRD: I think the message Error from server (NotFound): "myobj" not found is expected, as the CR was not actually created: /reopen
Reopened this issue. <detailsIn response to : still happening: I think the message Error from server (NotFound): "myobj" not found is expected, as the CR was not actually created: 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
yes, the actual error is later: Line 177 succeeds, and the next line fails:

Discussion:
} __EOF__ <ins> # Ensure the API server has recognized and started serving the associated CR API local tries=5 for i in $(seq 1 $tries); do local output output=$(kubectl "${kube_flags[@]:?}" api-resources --api-group mygroup.example.com -oname) if kube::test::if_has_string "$output" resources.mygroup.example.com; then break fi echo "${i}: Waiting for CR API to be available" sleep "$i" done </ins> # Dry-run create the CR kubectl "${kube_flags[@]:?}" apply --server-side --dry-run=server -f hack/testdata/CRD/resource.yaml "${kube_flags[@]:?}" # Make sure that the CR doesn't exist