jiebi/CodeConvo huggingface dataset:
Code 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 --e2e test fails with ECDSA Service Account key e2e test to succeed with ECDSA Service Account key Use ECDSA key for the service account key. Logs from the started test container: library defaults to by default as the only supported method while should be explicitly: Relevant code: On the API server side: Kubernetes version (use ): 1.21.0-rc.0 Cloud provider or hardware configuration: OS (e.g: ): Talos Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
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
Changing the service account key type to RSA fixes the test:
this is a problem for us, as this test is part of test suite, and it fails with 1.21-rc.0 e2e tests
SIG Auth own their test cases (it's tagged in the test name), SIG Architecture own conformance. Testing owns the frameworks, CI, tooling, etc. EDIT: just clarifying and making sure the right people see it. I raised this to the conformance work group.
/assign /priority critical-urgent /milestone v1.21 because this is in the conformance suite, it must not restrict valid+supported cluster configurations
/reopen the image needs to be promoted and bumped in the e2e test
Reopened this issue. <detailsIn response to : /reopen the image needs to be promoted and bumped in the e2e test 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
promote image PR:
I believe with merged this can be closed as all the fixes were done and backported to 1.21
Thanks!

Related discussion:
text: # agnhost: bump this one first - name: "agnhost" <del> version: "2.30" </del> <ins> version: "2.31" </ins> refPaths: - path: test/images/agnhost/VERSION match: d.d
Code 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 --e2e test fails with ECDSA Service Account key e2e test to succeed with ECDSA Service Account key Use ECDSA key for the service account key. Logs from the started test container: library defaults to by default as the only supported method while should be explicitly: Relevant code: On the API server side: Kubernetes version (use ): 1.21.0-rc.0 Cloud provider or hardware configuration: OS (e.g: ): Talos Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
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
Changing the service account key type to RSA fixes the test:
this is a problem for us, as this test is part of test suite, and it fails with 1.21-rc.0 e2e tests
SIG Auth own their test cases (it's tagged in the test name), SIG Architecture own conformance. Testing owns the frameworks, CI, tooling, etc. EDIT: just clarifying and making sure the right people see it. I raised this to the conformance work group.
/assign /priority critical-urgent /milestone v1.21 because this is in the conformance suite, it must not restrict valid+supported cluster configurations
/reopen the image needs to be promoted and bumped in the e2e test
Reopened this issue. <detailsIn response to : /reopen the image needs to be promoted and bumped in the e2e test 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
promote image PR:
I believe with merged this can be closed as all the fixes were done and backported to 1.21
Thanks!

Related discussion:
text: <del> 2.30 </del> <ins> 2.31 </ins>
Code 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 --e2e test fails with ECDSA Service Account key e2e test to succeed with ECDSA Service Account key Use ECDSA key for the service account key. Logs from the started test container: library defaults to by default as the only supported method while should be explicitly: Relevant code: On the API server side: Kubernetes version (use ): 1.21.0-rc.0 Cloud provider or hardware configuration: OS (e.g: ): Talos Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
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
Changing the service account key type to RSA fixes the test:
this is a problem for us, as this test is part of test suite, and it fails with 1.21-rc.0 e2e tests
SIG Auth own their test cases (it's tagged in the test name), SIG Architecture own conformance. Testing owns the frameworks, CI, tooling, etc. EDIT: just clarifying and making sure the right people see it. I raised this to the conformance work group.
/assign /priority critical-urgent /milestone v1.21 because this is in the conformance suite, it must not restrict valid+supported cluster configurations
/reopen the image needs to be promoted and bumped in the e2e test
Reopened this issue. <detailsIn response to : /reopen the image needs to be promoted and bumped in the e2e test 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
promote image PR:
I believe with merged this can be closed as all the fixes were done and backported to 1.21
Thanks!

Related discussion:
text: func main() { rootCmd := &cobra.Command{ Use:     "app", <del> Version: "2.30", </del> <ins> Version: "2.31", </ins> } rootCmd.AddCommand(auditproxy.CmdAuditProxy)
Code 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 --e2e test fails with ECDSA Service Account key e2e test to succeed with ECDSA Service Account key Use ECDSA key for the service account key. Logs from the started test container: library defaults to by default as the only supported method while should be explicitly: Relevant code: On the API server side: Kubernetes version (use ): 1.21.0-rc.0 Cloud provider or hardware configuration: OS (e.g: ): Talos Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
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
Changing the service account key type to RSA fixes the test:
this is a problem for us, as this test is part of test suite, and it fails with 1.21-rc.0 e2e tests
SIG Auth own their test cases (it's tagged in the test name), SIG Architecture own conformance. Testing owns the frameworks, CI, tooling, etc. EDIT: just clarifying and making sure the right people see it. I raised this to the conformance work group.
/assign /priority critical-urgent /milestone v1.21 because this is in the conformance suite, it must not restrict valid+supported cluster configurations
/reopen the image needs to be promoted and bumped in the e2e test
Reopened this issue. <detailsIn response to : /reopen the image needs to be promoted and bumped in the e2e test 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
promote image PR:
I believe with merged this can be closed as all the fixes were done and backported to 1.21
Thanks!

Related discussion:
text: } log.Printf("OK: Constructed OIDC provider for issuer %v", unsafeClaims.Issuer) <del> validTok, err := iss.Verifier(&oidc.Config{ClientID: audience}).Verify(ctx, raw) </del> <ins> validTok, err := iss.Verifier(&oidc.Config{ ClientID:             audience, SupportedSigningAlgs: []string{oidc.RS256, oidc.ES256}, }).Verify(ctx, raw) </ins> if err != nil { log.Fatal(err) }
Code 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 --pull-kubernetes-e2e-aks-engine-azure-file pull-kubernetes-e2e-azure-file-windows AzureFile CSI Driver End-to-End Tests: Dynamic Provisioning should create a volume on demand with mount options [] [] [Windows] AzureFile CSI Driver End-to-End Tests: Dynamic Provisioning should create multiple PV objects, bind to PVCs and attach all to different pods on the same node [] [] [Windows] AzureFile CSI Driver End-to-End Tests: Dynamic Provisioning should create a volume on demand and mount it as readOnly in a pod [] [] [Windows] If the randomly generated kubetest resource group has capital letters, the share name will contain invalid characters and fail provisioning. links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --
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

Related discussion:
text: } if shareName == "" { <del> // File share name has a length limit of 63, and it cannot contain two consecutive '-'s. </del> <ins> // File share name has a length limit of 63, it cannot contain two consecutive '-'s, and all letters must be lower case. </ins> name := util.GenerateVolumeName(a.options.ClusterName, a.options.PVName, 63) shareName = strings.Replace(name, "--", "-", -1) <ins> shareName = strings.ToLower(shareName) </ins> } if resourceGroup == "" {
Code change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --pull-kubernetes-integration runkubectldiff_tests It only shows failure cases in recent 2 days. The last date is I tried to reproduce it locally, but can't
/sig testing
/sig cli
/cc
I’ve only briefly taken a look at this, but my understanding is that server-side diff is flaking because the timestamp is different (by like a second) between the one already applied and the diff apply. do you think this could be related to this recent change Could delaying when we update the timestamp cause it to sometimes get misaligned with what’s being diffed? I’m not super familiar with diff, but it feels like it should ignore differences between timestamps that get updated on each call, right? Is there some sort of mechanism we have in that knows to ignore timestamps that just isn’t being done for fields?
This error probably shows that we have a path that causes the object to be re-written to etcd when it shouldn't.
As we can see, the diff only shows a difference in the timestamp but not in the fields that are managed. We are not supposed to update the timestamp if the managed fields haven't changed. That timestamp only gets updated if the two steps happen in different seconds (that's why it's flaky). That is definitely not a flake but an actual failure.
Failed 81/236 times today in /priority critical-urgent I think, correct it if I am wrong.
/triage accepted
correct. who should be assigned as the owner of this?
I can take it, I'm looking into it now
/assign

Related discussion:
text: // newDefaultFieldManager is a helper function which wraps a Manager with certain default logic. func newDefaultFieldManager(f Manager, typeConverter TypeConverter, objectConverter runtime.ObjectConvertor, objectCreater runtime.ObjectCreater, kind schema.GroupVersionKind, ignoreManagedFieldsFromRequestObject bool) *FieldManager { <del> f = NewManagedFieldsUpdater(f) f = NewStripMetaManager(f) f = NewBuildManagerInfoManager(f, kind.GroupVersion()) f = NewCapManagersManager(f, DefaultMaxUpdateManagers) f = NewProbabilisticSkipNonAppliedManager(f, objectCreater, kind, DefaultTrackOnCreateProbability) f = NewLastAppliedManager(f, typeConverter, objectConverter, kind.GroupVersion()) f = NewLastAppliedUpdater(f) return NewFieldManager(f, ignoreManagedFieldsFromRequestObject) </del> <ins> return NewFieldManager( NewLastAppliedUpdater( NewLastAppliedManager( NewProbabilisticSkipNonAppliedManager( NewCapManagersManager( NewBuildManagerInfoManager( NewManagedFieldsUpdater( NewStripMetaManager(f), ), kind.GroupVersion(), ), DefaultMaxUpdateManagers, ), objectCreater, kind, DefaultTrackOnCreateProbability, ), typeConverter, objectConverter, kind.GroupVersion()), ), ignoreManagedFieldsFromRequestObject, ) </ins> } // DecodeManagedFields converts ManagedFields from the wire format (api format)
Code change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --pull-kubernetes-integration runkubectldiff_tests It only shows failure cases in recent 2 days. The last date is I tried to reproduce it locally, but can't
/sig testing
/sig cli
/cc
I’ve only briefly taken a look at this, but my understanding is that server-side diff is flaking because the timestamp is different (by like a second) between the one already applied and the diff apply. do you think this could be related to this recent change Could delaying when we update the timestamp cause it to sometimes get misaligned with what’s being diffed? I’m not super familiar with diff, but it feels like it should ignore differences between timestamps that get updated on each call, right? Is there some sort of mechanism we have in that knows to ignore timestamps that just isn’t being done for fields?
This error probably shows that we have a path that causes the object to be re-written to etcd when it shouldn't.
As we can see, the diff only shows a difference in the timestamp but not in the fields that are managed. We are not supposed to update the timestamp if the managed fields haven't changed. That timestamp only gets updated if the two steps happen in different seconds (that's why it's flaky). That is definitely not a flake but an actual failure.
Failed 81/236 times today in /priority critical-urgent I think, correct it if I am wrong.
/triage accepted
correct. who should be assigned as the owner of this?
I can take it, I'm looking into it now
/assign

Related discussion:
text: live := &unstructured.Unstructured{} live.SetKind(gvk.Kind) live.SetAPIVersion(gvk.GroupVersion().String()) <del> f = NewStripMetaManager(f) f = NewManagedFieldsUpdater(f) f = NewBuildManagerInfoManager(f, gvk.GroupVersion()) f = NewProbabilisticSkipNonAppliedManager(f, &fakeObjectCreater{gvk: gvk}, gvk, DefaultTrackOnCreateProbability) f = NewLastAppliedManager(f, typeConverter, objectConverter, gvk.GroupVersion()) f = NewLastAppliedUpdater(f) </del> <ins> f = NewLastAppliedUpdater( NewLastAppliedManager( NewProbabilisticSkipNonAppliedManager( NewBuildManagerInfoManager( NewManagedFieldsUpdater( NewStripMetaManager(f), ), gvk.GroupVersion(), ), &fakeObjectCreater{gvk: gvk}, gvk, DefaultTrackOnCreateProbability, ), typeConverter, objectConverter, gvk.GroupVersion(), ), ) </ins> if chainFieldManager != nil { f = chainFieldManager(f) }
Code change:
kubelet logs misleading when volume limits not an
/sig storage /tirage accepted /assign
Note that it is set as info level in the log above: However, this is definitely confusing. /remove-kind bug /kind cleanup /triage accepted /sig node
I also have this problem Excuse me, how did you solve it
Which version do you use .. This was fixed here Check k8s version you use please

Related discussion:
text: for _, volumePlugin := range pluginWithLimits { attachLimits, err := volumePlugin.GetVolumeLimits() if err != nil { <del> klog.V(4).InfoS("Error getting volume limit for plugin", "plugin", volumePlugin.GetPluginName()) </del> <ins> klog.V(4).InfoS("Skipping volume limits for volume plugin", "plugin", volumePlugin.GetPluginName()) </ins> continue } for limitKey, value := range attachLimits {
Code change:
The test only validates that the API objects are created E2e tests must verify the behaviour, i.e. that the Service and Endpoints actually work sending traffic. The file is not well organized and there is a lot of duplicate code, one possibility is to use current Services helper has a function to test the reachability that iterates over all service ports However, something that needs to be addressed is that the pods that are backing the service doesn't have any process listening on those ports
/help wanted /sig network /priority important-soon /triage accepted
I think that there are more tests that doesn't verify the reachability , those should be modified too /help-wanted
/help-wanted
/assign
/triage accepted
/assign /unassign I will take on this since it was more difficult than I expected, and is a Conformance test.. I assigned you to , that is similar to this, but creating a new test from scratch

Related discussion:
text: err := cs.CoreV1().Services(ns).Delete(context.TODO(), serviceName, metav1.DeleteOptions{}) framework.ExpectNoError(err, "failed to delete service: %s in namespace: %s", serviceName, ns) }() <del> _, err := jig.CreateTCPServiceWithPort(nil, 80) </del> <ins> svc, err := jig.CreateTCPServiceWithPort(nil, 80) </ins> framework.ExpectNoError(err) validateEndpointsPortsOrFail(cs, ns, serviceName, portsByPodName{})
Code change:
The test only validates that the API objects are created E2e tests must verify the behaviour, i.e. that the Service and Endpoints actually work sending traffic. The file is not well organized and there is a lot of duplicate code, one possibility is to use current Services helper has a function to test the reachability that iterates over all service ports However, something that needs to be addressed is that the pods that are backing the service doesn't have any process listening on those ports
/help wanted /sig network /priority important-soon /triage accepted
I think that there are more tests that doesn't verify the reachability , those should be modified too /help-wanted
/help-wanted
/assign
/triage accepted
/assign /unassign I will take on this since it was more difficult than I expected, and is a Conformance test.. I assigned you to , that is similar to this, but creating a new test from scratch

Related discussion:
text: name1 := "pod1" name2 := "pod2" <del> createPodOrFail(f, ns, name1, jig.Labels, []v1.ContainerPort{{ContainerPort: 80}}) </del> <ins> createPodOrFail(f, ns, name1, jig.Labels, []v1.ContainerPort{{ContainerPort: 80}}, "netexec", "--http-port", "80") </ins> names[name1] = true validateEndpointsPortsOrFail(cs, ns, serviceName, portsByPodName{name1: {80}}) <del> createPodOrFail(f, ns, name2, jig.Labels, []v1.ContainerPort{{ContainerPort: 80}}) </del> <ins> ginkgo.By("Checking if the Service forwards traffic to pod1") execPod := e2epod.CreateExecPodOrFail(cs, ns, "execpod", nil) err = jig.CheckServiceReachability(svc, execPod) framework.ExpectNoError(err) createPodOrFail(f, ns, name2, jig.Labels, []v1.ContainerPort{{ContainerPort: 80}}, "netexec", "--http-port", "80") </ins> names[name2] = true validateEndpointsPortsOrFail(cs, ns, serviceName, portsByPodName{name1: {80}, name2: {80}}) <ins> ginkgo.By("Checking if the Service forwards traffic to pod1 and pod2") err = jig.CheckServiceReachability(svc, execPod) framework.ExpectNoError(err) </ins> e2epod.DeletePodOrFail(cs, ns, name1) delete(names, name1) validateEndpointsPortsOrFail(cs, ns, serviceName, portsByPodName{name2: {80}}) <ins> ginkgo.By("Checking if the Service forwards traffic to pod2") err = jig.CheckServiceReachability(svc, execPod) framework.ExpectNoError(err) </ins> e2epod.DeletePodOrFail(cs, ns, name2) delete(names, name2) validateEndpointsPortsOrFail(cs, ns, serviceName, portsByPodName{})
Code change:
The test only validates that the API objects are created E2e tests must verify the behaviour, i.e. that the Service and Endpoints actually work sending traffic. The file is not well organized and there is a lot of duplicate code, one possibility is to use current Services helper has a function to test the reachability that iterates over all service ports However, something that needs to be addressed is that the pods that are backing the service doesn't have any process listening on those ports
/help wanted /sig network /priority important-soon /triage accepted
I think that there are more tests that doesn't verify the reachability , those should be modified too /help-wanted
/help-wanted
/assign
/triage accepted
/assign /unassign I will take on this since it was more difficult than I expected, and is a Conformance test.. I assigned you to , that is similar to this, but creating a new test from scratch

Related discussion:
text: svc2port := "svc2" ginkgo.By("creating service " + serviceName + " in namespace " + ns) <del> _, err := jig.CreateTCPService(func(service *v1.Service) { </del> <ins> svc, err := jig.CreateTCPService(func(service *v1.Service) { </ins> service.Spec.Ports = []v1.ServicePort{ { Name:       "portname1",