jiebi/CodeConvo huggingface dataset:
Change:
} { t.Run(tc.desc, func(t *testing.T) { set := burst(newStatefulSet(0)) <ins> set.Spec.VolumeClaimTemplates[0].ObjectMeta.Labels = map[string]string{"test": "test"} </ins> parallelScale(t, set, tc.replicas, tc.desiredReplicas, assertBurstInvariants) }) }

Discussion:
The kube-controller-manage may crash when processing StatefulSet with spec.podManagementPolicy is Parallel. With logs: we expect the kube-controller-manage will work well. The following example can reproduce this problem: After digging into the source code, we found that when using the pod management policy, the statefulset controller will use to start parallel processing. But the which is called during parallel processing may directly update the claims' labels without a lock. This finally causes a concurrent map-accessing problem. <details</details<details</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
/sig apps
Thanks for the report. Do we know when this issue was introduced? cc
Maybe it was imported by this pr
We can reproduce this issue in unit testing.
The reported versions is and it seems that PR got backported further /priority important-soon
/assign
The original report looks like could have introduced it, yes. I wonder if we intentionally modify template without creating a copy (and as it seems, assign the exact same labels every time we use this template for any pod): Regardless, that was probably safe before the pod creations were parallelized. I don't think the proposed unit test catches the bug (more on that below), but we can probably reproduce it by timing pod state transitions so that many pods are simultaneously pending and missing a PVC. I ran this test on (before the cherry-pick of parallel statefulset scaling), and it also failed. This is because the test itself introduces a concurrent map write. It probably doesn't replicate the issue, and I don't think it can be merged, as it'll fail even if the original PR is reverted. For reproduction we'd need to catch a concurrent write without adding one in test code, just as it happened based on the original report.
Turns out we never tested this path at all, since the test PVC didn't have any labels of its own.

After adding labels, existing tests are sufficient to detect race condition. PR showing that improved test detects the issue: PR with fix and improved test:
Sweet! thanks !
Change:
assert.Equal(t, http.StatusOK, resp.StatusCode) } <ins> func TestTrimURLPath(t *testing.T) { tests := []struct { path, expected string }{ {"", ""}, {"//", ""}, {"/pods", "pods"}, {"pods", "pods"}, {"pods/", "pods"}, {"good/", "good"}, {"pods/probes", "pods"}, {"metrics", "metrics"}, {"metrics/resource", "metrics/resource"}, {"metrics/hello", "metrics/hello"}, } for _, test := range tests { assert.Equal(t, test.expected, trimURLPath(test.path), fmt.Sprintf("path is: %s", test.path)) } } </ins>

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : 1) add metrics into kubelet to monitor ; 2) add throttling to . Why is this needed: Kubelet provides lots of its functionalities through its http server, and currently there is no server-side monitoring and throttling mechanisms. Adding metrics into kubelet to monitor its http server will improve its observability and debuggability; adding throttling will prevent kubelet being overloaded from serving too many http requests.
/sig node
Change:
close(stopChan) // wait for r.ForwardPorts to actually return <del> select { case err := <-doneChan: if err != nil { t.Fatalf("%d: unexpected error: %s", err) } case <-time.After(200 * time.Millisecond): t.Fatalf("%d: timeout waiting for ForwardPorts to finish") </del> <ins> err = <-doneChan if err != nil { t.Fatalf("%d: unexpected error: %s", err) </ins> } if e, a := len(testCase.Send), len(conn.streams); e != a {

Discussion:
this is you
Hmm, I had upped waiting from 100ms to 500ms and that seemed to fix it. Do you have any better ideas?
Don't wait? :)
If the only reason you would timeout would be the code is broken, that's why the test runs have -timeout set.
Then the test fails immediately. It's waiting for the net.Listen calls to finish so it can connect to the specified local ports.
*finish enough so that socket connections work
So I can remove the timeout gating in my tests?
Yes ----- Original Message -----
Just failed again: https://travis-
Seems to be failing frequently now.
If this is test is failing again, my gut says it's not the same root cause. The original failure was a timeout issue. This new one is connection reset by peer. I've got the test running in a loop waiting for a failure but haven't seen one yet. is this still failing frequently?
No. It had failed twice in ~10 builds when I reopened this issue, but hasn't failed since. Reclosing. Will file a new issue if it recurs.
Change:
"github.com/google/gofuzz" ) <ins> func TestIsList(t *testing.T) { tests := []struct { obj    runtime.Object isList bool }{ {&api.PodList{}, true}, {&api.Pod{}, false}, } for _, item := range tests { if e, a := item.isList, runtime.IsListType(item.obj); e != a { t.Errorf("%v: Expected %v, got %v", reflect.TypeOf(item.obj), e, a) } } } </ins> func TestExtractList(t *testing.T) { pl := &api.PodList{ Items: []api.Pod{

Discussion:
Had a report of this over email. Filing this issue so we don't forget to investigate.
Can't reproduce.
Change:
} if *build { <del> if !runBash("build", `test-build-release`) { </del> <ins> if !run("build-local", "hack/build-go.sh") { log.Fatal("Error building. Aborting.") } if !runBash("build-release", `test-build-release`) { </ins> log.Fatal("Error building. Aborting.") } }

Discussion:
building release, hopefully it's just binary missing; but i expect e2e-test to build binary automatically.
Steps to reproduce? /cc
Just run hack/e2e-, will fail. The _output/go/bin directory only has integration binary. (tried run first, still fails).
Did you try hack/build- first? e2e is in the default target list:
It's also in the client target list in the new build infrastructure:
Ah, I think that will do the trick. I didn't run hack/build-, as I saw e2e- output something like this (A little misleading if it won't build the binary). Re-running test now, will close the issue if it works. But it would be great if the binary will be built automatically.
I agree it should be built automatically. Otherwise, we'd at least have to update our e2e documentation.
Ah, yeah, I ran into this too and haven't fixed it yet. I this cmd/e2e to the build system, where does it end up? Apparently not in _output...
Change:
# arguments: # $@: all stuff that goes after 'gcloud compute ' function run-gcloud-compute-with-retries { <ins> echo "" > /tmp/gcloud_retries </ins> for attempt in $(seq 1 ${RETRIES}); do <del> if ! gcloud compute $@; then </del> <ins> if ! gcloud compute $@ &> /tmp/gcloud_retries; then if [[ $(grep -c "already exists" /tmp/gcloud_retries) -gt 0 ]]; then if [[ "${attempt}" == 1 ]]; then echo -e "${color_red} Failed to $1 $2 $3 as the resource hasn't been deleted from a previous run.${color_norm}" >& 2 exit 1 fi echo -e "${color_yellow}Succeeded to $1 $2 $3 in the previous attempt, but status response wasn't received.${color_norm}" return 0 fi </ins> echo -e "${color_yellow}Attempt $(($attempt+1)) failed to $1 $2 $3. Retrying.${color_norm}" >& 2 sleep $(($attempt * 5)) else

Discussion:
https://k8s- Failed: Kubemark {} Previous issues for this test:
Builds: ci-kubernetes-kubemark-5-gce Failed: Kubemark {}
There are few things here: 3443 run - can you please invstigate it? 3480 run - gcloud copy-files should be retried 3550 run - we should better handle "already exists" errors (and not retry them). I think was looking into it at some point, so he may have already did something
https://k8s- Failed: Kubemark {}
I was looking at 'already exists' problem in RouteController, not in Kubemark.
Builds: ci-kubernetes-kubemark-5-gce Failed: Kubemark {}
Here are the causes of the above tests to fail and fixes: Test Fix ------ ------ ci-kubernetes-kubemark-5-gce/3443 Ignore (as its super flaky) or change create-certs/generate-certs to use a different directory ci-kubernetes-kubemark-5-gce/3480 Run the copy-files with retries as it is idempotent ci-kubernetes-kubemark-5-gce/3550 Don't retry when resource already exists ci-kubernetes-kubemark-5-gce/3666 Not worry as it is flaky or add retrying logic to all gclouds in that script ci-kubernetes-kubemark-5-gce/3787 Run the ssh with retries as it is idempotent
This PR fixes issues with the 2nd, 3rd and 5th tests in the above table. Could you PTAL at the PR? Also, I think we can safely ignore the 1st test (which is super flaky) and what do you suggest about the 4th test (do we add retrying logic to just call inside detect-master function of or let it stay as it is because there are a lot of other such gcloud calls inside the file, all of which should be changed rightfully)?
Let's not fix everything - fix just the things that you need, and direct vicinity.
Ok. So then let's ignore the 1st and the 4th tests in the above table as they are not really important. 2nd, 3rd and 5th are solved by PR . And regarding failure of , it looks like it is a flaky issue as well.

The density test succeeded, but the load test failed. From the logs it appears to be an issue with the client caches returning old resource versions for pod watches, with many such log statements: Does this worry you or you'd deem it to be just some weird flake?
It might mean a number of things, but most likely something gets overloaded/congested. It might be hard to debug, as we're seeing this from time to time, but it doesn't look very serious so I think we never investigated it thoroughly.
Change:
t.Errorf("Expected expectedVolumesNeedDevicePath:n%vn got:n%v", expectedVolumes, rcInstance.volumesNeedUpdateFromNodeStatus) } <del> expectedVolumes = make([]v1.UniqueVolumeName, len(tc.expectedVolumesNeedReportedInUse)) for i := range tc.expectedVolumesNeedReportedInUse { expectedVolumes[i] = v1.UniqueVolumeName(tc.expectedVolumesNeedReportedInUse[i]) } if !reflect.DeepEqual(expectedVolumes, rcInstance.volumesNeedReportedInUse) { t.Errorf("Expected volumesNeedReportedInUse:n%vn got:n%v", expectedVolumes, rcInstance.volumesNeedReportedInUse) } </del> volumesFailedReconstruction := sets.NewString() for _, vol := range rcInstance.volumesFailedReconstruction { volumesFailedReconstruction.Insert(vol.volumeSpecName)

Discussion:
remove and was introduced in to fix This is to overcome the situation that volume is to DSW at first and then deleted before it is to ASW, which causes mounted volume neither in DSW nor ASW and won't execute unmount/detach: The reason the volume cannot be to ASW in time is , which is . However, there is another PR also solved the issue. What it did is to check whether ASW already has the volume before deleting it from DSW, this makes sure that volume can be detached/unmounted after it is deleted from DSW. I suggest that we can keep the second solution and remove related code to make the reconstruction process and reconcile loop cleaner?
/sig storage
cc
Should I proceed with this issue? Your guidance is appreciated.
I think we'd better wait for the feedback from
cc
Sorry for a late reply. This is how behind we are with reviews :-(. Reading Now that is on by default, it reconstructs volumes first and always puts them to ASW, it should never happen that a reconstructed volume is in DSW and not in ASW, right? So we can remove easily. I would not be so sure without , because the code is 5 years old and who knows all the implications. You could be right though, it may not be necessary there too.
/triage accepted
/assign
Change:
} ginkgo.BeforeEach(func() { <ins> // Precautionary check that kubelet is healthy before running the test. waitForKubeletToStart(context.TODO(), f) </ins> ginkgo.By("setting up the pod to be used in the test") e2epod.NewPodClient(f).Create(context.TODO(), testCase.podSpec) })

Discussion:
ci-cgroupv1-containerd-node-arm64-e2e-serial-ec2-eks ci-cgroupv1-containerd-node-e2e-serial-ec2-eks It has been failing consistently for a long time. No response /sig node
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/cc
There's another bug that was filed a long time ago. But there's no update on it and the same test in gce jobs seem to be green now.
cc
Change:
The following environment variables should refer to keys and certificates on the host that are specific to that host. - `FLOCKER_CONTROL_SERVICE_CA_FILE` should refer to the full path to the cluster certificate file <del> - `FLOCKER_CONTROL_SERVICE_CLIENT_KEY_FILE` should refer to the full path to the key file for the API user - `FLOCKER_CONTROL_SERVICE_CLIENT_CERT_FILE` should refer to the full path to the certificate file for the API user </del> <ins> - `FLOCKER_CONTROL_SERVICE_CLIENT_KEY_FILE` should refer to the full path to the [api key](https://docs.clusterhq.com/en/latest/config/generate-api-plugin.html) file for the API user - `FLOCKER_CONTROL_SERVICE_CLIENT_CERT_FILE` should refer to the full path to the [api certificate](https://docs.clusterhq.com/en/latest/config/generate-api-plugin.html) file for the API user </ins> More details regarding cluster authentication can be found at the documentation: [Flocker Cluster Security & Authentication](https://docs.clusterhq.com/en/latest/concepts/security.html) and [Configuring Cluster Authentication](https://docs.clusterhq.com/en/latest/config/configuring-authentication.html). ### Create a pod with a Flocker volume <del> **Note**: A new dataset must first be provisioned using the Flocker tools. For example, using the [Volumes CLI](https://docs.clusterhq.com/en/latest/labs/volumes-cli.html)), create a new dataset called 'my-flocker-vol' of size 10GB: </del> <ins> **Note**: A new dataset must first be provisioned using the Flocker tools or Docker CLI *(To use the Docker CLI, you need the [Flocker plugin for Docker](https://clusterhq.com/docker-plugin/) installed along with Docker 1.9+)*. For example, using the [Volumes CLI](https://docs.clusterhq.com/en/latest/labs/volumes-cli.html), create a new dataset called 'my-flocker-vol' of size 10GB: </ins> ```sh <del> flocker-volumes create -m name=my-flocker-vol -s 10G </del> <ins> flocker-volumes create -m name=my-flocker-vol -s 10G -n <node-uuid> # -n or --node= Is the initial primary node for dataset (any unique # prefix of node uuid, see flocker-volumes list-nodes) </ins> ``` The following *volume* spec from the [example pod](flocker-pod.yml) illustrates how to use this Flocker dataset as a volume. <ins> > Note, the [example pod](flocker-pod.yml) used here does not include a replication controller, therefore the POD will not be rescheduled upon failure. If your looking for an example that does include a replication controller and service spec you can use [this example pod including a replication controller](flocker-pod-with-rc.yml) </ins> ```yaml volumes: - name: www-root

Discussion:
We found that some users coming to the document were getting a little confused. It should include more detail about where to install Flocker services, how to set environment variables, that you can create volumes now with Docker CLI and give more detail in example including how to use it with a spec that includes a replication controller.
Change:
func Test_growSlice(t *testing.T) { type args struct { initialCapacity int <ins> initialLen      int </ins> v               reflect.Value maxCapacity     int sizes           []int

Discussion:
has by default, and since 1.22 has the same. They seem to return wrong results in certain situations combined with / . And / also use , so they also don't work correctly. outputs partial list of pods on the node, doesn't evict some of the pods. To make it work correctly, I had to specify works correctly with any , since it's just a performance optimizing parameter. I can't provide an actual concrete example (no = default ), but instead I show how to reproduce it with a smaller I believe that the same problem occurs with create two deployments. there are 5 pods in each. with --selector=app=another-server and , it shows only 4 pods. I could confirm that the problem happens in both case of and regardless namespace, even with , or <details</details<detailsGCP / GKE Standard </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
/sig api-machinery
/sig node
I think this is indeed a bug, after some simple testing, it seems to be an bug unique to 1.24, let me fix it. /assign
/assign
I can reproduce this error in a 1.24 cluster, but not in a 1.23.6 cluster. All clusters are created via kind, and I'm guessing gke may have cherry-picked some commits or had some of their own changes to their branch. So I think this fix should at least cherry-pick to 1.23 to help other distributions fix this issue.
/remove-sig api-machinery
Change:
COPY --from=prep /dig-dir /dig COPY --from=prep /vcruntime140.dll /Windows/System32/ <ins> # include nltest COPY --from=servercore-helper /Windows/System32/nltest.exe /Windows/System32/nltest.exe COPY --from=servercore-helper /Windows/System32/en-US/nltest.exe.mui /Windows/System32/en-US/nltest.exe.mui COPY --from=servercore-helper /Windows/System32/ntdsapi.dll /Windows/System32/ntdsapi.dll </ins> # include powershell and its Module analysis cache. COPY --from=ps-helper ["/PowerShell", "/Program Files/PowerShell"]

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI -- [sig-windows] [Feature:Windows] GMSA Kubelet [Slow] kubelet GMSA support when creating a pod with correct GMSA credential specs passes the credential specs down to the Pod's containers [sig-windows] [Feature:Windows] GMSA Full [Serial] [Slow] GMSA support works end to end ** pause image using in image was transitioned to the official pause image which no longer has in the image related to /sig windows /triage accepted
Change:
glog.V(3).Infof("Setting up volume %v for pod %v at %v", b.volName, b.pod.UID, dir) // Wrap EmptyDir, let it do the setup. <del> wrapped, err := b.plugin.host.NewWrapperMounter(b.volName, wrappedVolumeSpec, &b.pod, *b.opts) </del> <ins> wrapped, err := b.plugin.host.NewWrapperMounter(b.volName, wrappedVolumeSpec(), &b.pod, *b.opts) </ins> if err != nil { return err }

Discussion:
Data as of June 3rd, 9:00 PM Eastern. Latest data can be found here: Prow link to the 2 jobs: * Additional Context:
/sig storage cc
I'm working on , it's hard to get a job yaml right at the first time. I'll check iscsi. /assign
/triage accepted /kind failing-test
ci-kubernetes-e2e-storage-kind-disruptive fixed: has 1 green run pull-kubernetes-e2e-storage-kind-disruptive fixed: , it fails when it should fail, it's green otherwise, I'll continue with iscsi.
/reopen it's still red, but at least it installs now:
Reopened this issue. <detailsIn response to : /reopen it's still red, but at least it installs now: 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
e2e-gce-iscsi-serial job passes now: e2e-gce-iscsi is getting greener: I'll let it run for few more days to see if today's failures are flakes. /reopen
Reopened this issue. <detailsIn response to : It's getting greener: /reopen </details
iscsi-serial is green:
Change:
}, enableSchedulingGates: true, }, <ins> { name: "addition to nodeAffinity is allowed for gated pods with nil affinity", create: &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: "test-pod", }, Spec: v1.PodSpec{ Containers: []v1.Container{ { Name:  "fake-name", Image: "fakeimage", }, }, SchedulingGates: []v1.PodSchedulingGate{{Name: "baz"}}, }, }, update: &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: "test-pod", }, Spec: v1.PodSpec{ Containers: []v1.Container{ { Name:  "fake-name", Image: "fakeimage", }, }, Affinity: &v1.Affinity{ NodeAffinity: &v1.NodeAffinity{ RequiredDuringSchedulingIgnoredDuringExecution: &v1.NodeSelector{ // Add 1 MatchExpression and 1 MatchField. NodeSelectorTerms: []v1.NodeSelectorTerm{ { MatchExpressions: []v1.NodeSelectorRequirement{ { Key:      "expr", Operator: v1.NodeSelectorOpIn, Values:   []string{"foo"}, }, }, MatchFields: []v1.NodeSelectorRequirement{ { Key:      "metadata.name", Operator: v1.NodeSelectorOpIn, Values:   []string{"foo"}, }, }, }, }, }, }, }, SchedulingGates: []v1.PodSchedulingGate{{Name: "baz"}}, }, }, enableSchedulingGates: true, }, </ins> } for _, tc := range cases { defer featuregatetesting.SetFeatureGateDuringTest(t, utilfeature.DefaultFeatureGate, features.PodSchedulingReadiness, tc.enableSchedulingGates)()

Discussion:
When a gated pod is created with nil affinity and a user/controller tries to update its nodeAffinity, the validation fails. The pod gets updated with the new affinity as per rules in a pod as in the following using : to update the pod as with: No response <details</details<detailsTested on kind and OpenShift </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
/sig scheduling