jiebi/CodeConvo huggingface dataset:
Change:
err = wait.PollImmediate(podTemplateRetryPeriod, podTemplateRetryTimeout, checkPodTemplateListQuantity(f, "podtemplate-set=true", 0)) framework.ExpectNoError(err, "failed to count required pod templates") <ins> }) ginkgo.It("should replace a pod template", func() { ptClient := f.ClientSet.CoreV1().PodTemplates(f.Namespace.Name) ptName := "podtemplate-" + utilrand.String(5) ginkgo.By("Create a pod template") ptResource, err := ptClient.Create(context.TODO(), &v1.PodTemplate{ ObjectMeta: metav1.ObjectMeta{ Name: ptName, }, Template: v1.PodTemplateSpec{ Spec: v1.PodSpec{ Containers: []v1.Container{ {Name: "e2e-test", Image: imageutils.GetE2EImage(imageutils.Agnhost)}, }, }, }, }, metav1.CreateOptions{}) framework.ExpectNoError(err, "failed to create pod template") ginkgo.By("Replace a pod template") var updatedPT *v1.PodTemplate err = retry.RetryOnConflict(retry.DefaultRetry, func() error { ptResource, err = ptClient.Get(context.TODO(), ptName, metav1.GetOptions{}) framework.ExpectNoError(err, "Unable to get pod template %s", ptName) ptResource.Annotations = map[string]string{ "updated": "true", } updatedPT, err = ptClient.Update(context.TODO(), ptResource, metav1.UpdateOptions{}) return err }) framework.ExpectNoError(err) framework.ExpectEqual(updatedPT.Annotations["updated"], "true", "updated object should have the applied annotation") framework.Logf("Found updated podtemplate annotation: %#vn", updatedPT.Annotations["updated"]) </ins> }) })

Discussion:
[x] test approval issue : [x] test pr : [x] two weeks soak end date : 14 March 2022 [X] test promotion pr : According to this APIsnoop query, there is still one remaining PodTemplate endpoint which is untested. Using a number of existing e2e test practices a new has been created for pod templates. The e2e logs for this test are listed below. This query shows the endpoints hit within a short period of running the e2e test If a test with these calls gets merged, test coverage will go up by 1 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
Change:
}) } } <ins> func TestIsErrorTypesByReasonAndCode(t *testing.T) { testCases := []struct { name                  string knownReason           metav1.StatusReason otherReason           metav1.StatusReason otherReasonConsidered bool code                  int32 fn                    func(error) bool }{ { name:                  "IsRequestEntityTooLarge", knownReason:           metav1.StatusReasonRequestEntityTooLarge, otherReason:           metav1.StatusReasonForbidden, otherReasonConsidered: false, code:                  http.StatusRequestEntityTooLarge, fn:                    IsRequestEntityTooLargeError, }, { name:                  "TooManyRequests", knownReason:           metav1.StatusReasonTooManyRequests, otherReason:           metav1.StatusReasonForbidden, otherReasonConsidered: false, code:                  http.StatusTooManyRequests, fn:                    IsTooManyRequests, }, { name:                  "Forbidden", knownReason:           metav1.StatusReasonForbidden, otherReason:           metav1.StatusReasonNotFound, otherReasonConsidered: true, code:                  http.StatusForbidden, fn:                    IsForbidden, }, { name:                  "NotFound", knownReason:           metav1.StatusReasonNotFound, otherReason:           metav1.StatusReasonForbidden, otherReasonConsidered: true, code:                  http.StatusNotFound, fn:                    IsNotFound, }, } for _, tc := range testCases { t.Run(tc.name, func(t *testing.T) { t.Run("by known reason", func(t *testing.T) { err := &StatusError{ metav1.Status{ Reason: tc.knownReason, }, } got := tc.fn(err) if !got { t.Errorf("expected reason %s to match", tc.knownReason) } }) t.Run("by code and unknown reason", func(t *testing.T) { err := &StatusError{ metav1.Status{ Reason: metav1.StatusReasonUnknown, // this could be _any_ reason that isn't in knownReasons. Code:   tc.code, }, } got := tc.fn(err) if !got { t.Errorf("expected code %d with reason %s to match", tc.code, tc.otherReason) } }) if !tc.otherReasonConsidered { return } t.Run("by code and other known reason", func(t *testing.T) { err := &StatusError{ metav1.Status{ Reason: tc.otherReason, Code:   tc.code, }, } got := tc.fn(err) if got { t.Errorf("expected code %d with reason %s to not match", tc.code, tc.otherReason) } }) }) } } </ins>

Discussion:
Checked a method error using when the error was caused by a validating webhook that returns a 403 response. In this particular case, the error was generated from a validating webhook implemented with controller-runtime that returns controller-runtime's response. to return true. returned false Many (but not all) of the other family of functions in suffer the same kind of problem. I have changes ready to submit in a PR if we can get agreement that this is a problem and that it should be fixed in the functions that ought to check the of an erorr value that is or wraps an Kubernetes version (use ): 19.3 for the server
/sig api-machinery
are you going to send a PR for this? The issue description looks reasonable. /triage accepted
Thanks, PR is submitted.
/assign
Change:
framework.ExpectNoError(err, "failed to ensure number of pods associated with job %s is equal to parallelism count in namespace: %s", job.Name, f.Namespace.Name) ginkgo.By("Updating the job with suspend=true") <del> job, err = e2ejob.GetJob(f.ClientSet, f.Namespace.Name, job.Name) framework.ExpectNoError(err, "failed to retrieve latest job object") job.Spec.Suspend = pointer.BoolPtr(true) job, err = e2ejob.UpdateJob(f.ClientSet, f.Namespace.Name, job) </del> <ins> err = wait.PollImmediate(framework.Poll, framework.SingleCallTimeout, func() (bool, error) { job, err = e2ejob.GetJob(f.ClientSet, f.Namespace.Name, job.Name) if err != nil { return false, err } job.Spec.Suspend = pointer.Bool(true) updatedJob, err := e2ejob.UpdateJob(f.ClientSet, f.Namespace.Name, job) if err == nil { job = updatedJob return true, nil } if apierrors.IsConflict(err) { return false, nil } return false, err }) </ins> framework.ExpectNoError(err, "failed to update job in namespace: %s", f.Namespace.Name) ginkgo.By("Ensuring pods are deleted")

Discussion:
sig-release-master-blocking gce-cos-master-default Kubernetes e2e suite.[sig-apps] Job should delete pods when suspended not clear No response /sig apps 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
cc
/assign
Candidate (I'll run the suite a few times)
Change:
var cache *schedulerCache var snapshot *Snapshot <del> type operation = func() </del> <ins> type operation = func(t *testing.T) </ins> addNode := func(i int) operation { <del> return func() { </del> <ins> return func(t *testing.T) { </ins> if err := cache.AddNode(nodes[i]); err != nil { t.Error(err) } } } removeNode := func(i int) operation { <del> return func() { </del> <ins> return func(t *testing.T) { </ins> if err := cache.RemoveNode(nodes[i]); err != nil { t.Error(err) } } } updateNode := func(i int) operation { <del> return func() { </del> <ins> return func(t *testing.T) { </ins> if err := cache.UpdateNode(nodes[i], updatedNodes[i]); err != nil { t.Error(err) } } } addPod := func(i int) operation { <del> return func() { </del> <ins> return func(t *testing.T) { </ins> if err := cache.AddPod(pods[i]); err != nil { t.Error(err) } } } addPodWithAffinity := func(i int) operation { <del> return func() { </del> <ins> return func(t *testing.T) { </ins> if err := cache.AddPod(podsWithAffinity[i]); err != nil { t.Error(err) } } } removePod := func(i int) operation { <del> return func() { </del> <ins> return func(t *testing.T) { </ins> if err := cache.RemovePod(pods[i]); err != nil { t.Error(err) } } } removePodWithAffinity := func(i int) operation { <del> return func() { </del> <ins> return func(t *testing.T) { </ins> if err := cache.RemovePod(podsWithAffinity[i]); err != nil { t.Error(err) } } } updatePod := func(i int) operation { <del> return func() { </del> <ins> return func(t *testing.T) { </ins> if err := cache.UpdatePod(pods[i], updatedPods[i]); err != nil { t.Error(err) } } } updateSnapshot := func() operation { <del> return func() { </del> <ins> return func(t *testing.T) { </ins> cache.UpdateSnapshot(snapshot) if err := compareCacheWithNodeInfoSnapshot(t, cache, snapshot); err != nil { t.Error(err)

Discussion:
/sig scheduling What happened: reverted an old behavior to ensure Pod information is not lost when Nodes are recreated without its Pods getting recreated. A ghost Pod is kep in The problem is that we rely in this map for determining deleted Nodes when updating the snapshot in . The good thing is that the nodeinfo's are cloned into the snapshot, so we shouldn't have nil pointer accesses. But we might lose a few cycles trying to schedule on nodes that are deleted How to reproduce it (as minimally and precisely as possible): a node with a few pods. node without deleting pods. Result: The snapshot still has the node. Environment: Kubernetes version (use ): 1.18+
/assign
It actually produces the error: which would cause failed scheduling cycles (the map is not recreated, only the lists).
Change:
}, }, expectedDevicePath:      "/dev/rbd1", <del> expectedDeviceMountPath: fmt.Sprintf("%s/plugins/kubernetes.io/rbd/rbd/pool1-image-image1", tmpDir), </del> <ins> expectedDeviceMountPath: fmt.Sprintf("%s/plugins/kubernetes.io/rbd/mounts/pool1-image-image1", tmpDir), </ins> expectedPodMountPath:    fmt.Sprintf("%s/pods/%s/volumes/kubernetes.io~rbd/vol1", tmpDir, podUID), }) cases = append(cases, &testcase{

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: The method for ceph rbd volume plugin generates the path with code as follows: So the device mount path's format will be: , this implementation has two problems: with other volume plugins, as all the other plugins return , see as an example. method of ceph rbd plugin is not working properly, because rbd plugin uses method to find the device mount path(just like all the other plugins do), and method assumes the device mount path's format is (see ). What you expected to happen: The device mount path of rbd plugin should be . Anything else we need to know?: Do we have any reason for this design? If not, I will submit a PR to fix this, the adjusted method maybe look like this: /sig storage
/assign
nice catch There are two ways to fix this: Change mount path. But this will introduce compatibility issues during upgrade. Use , instead of to replace PR welcome
cc
Hi , there is a difference between and : returns the device path, such as , and returns the device mounted path, such as . What we really want is the second one, as we need to find the pool and image name. So we can't just simply replace with . Maybe we can find the mounted path specially for rbd plugin, use , the code looks like this:
thanks let make a forward moving plan: fix and append to the global path keep in . If no path is found, fall back to old path scheme using your code
Nice idea , I've submit a PR for this, PTAL.
I've checked and the reason is that I tested with the old release branch, the has been changed with in mount path, and causes the problem. thanks for your PR
i read again. There is another return path . So in rbd, the missing dir will not make into , but the second return should still give us the dir we need
You are right , indeed has two return path, but the second return still can't meet our needs. Because the parameter of is the mount path for a specific pod, such as , its format is , so will return the volume name. This volume name is returned by (see ), usually is the PV's name or the name specified in , both of these are not .
Change:
It("should surface a failure condition on a common issue like exceeded quota", func() { rcConditionCheck(f) }) <ins> It("should adopt matching pods on creation", func() { testRCAdoptMatchingOrphans(f) }) It("should release no longer matching pods", func() { testRCReleaseControlledNotMatching(f) }) </ins> }) func newRC(rsName string, replicas int32, rcPodLabels map[string]string, imageName string, image string) *v1.ReplicationController {

Discussion:
The merge queue is green with RBAC enabled, and the replicaset controller was missing permission to patch pods until fixed in Pod adoption and release depend on patching pods, which means that there are no merge-queue-blocking tests that test these features. Given that they are complex and rarely tested manually, we need tests that run as part of the merge queue to ensure they function correctly.
I'd like to work on this, where should the tests be ? I see that there are some patch-related tests for the replicaset controller in , and, according to http://submit-, the integration tests are run as part of the merge queue, is that correct? Thanks!
I think we'd want an e2e test that drives behavior externally on a normal cluster (by creating a replicaset, waiting to observe expected pods, modifies replicaset, waits to observe expected results, etc) . many of the integration tests tend to start up fake servers that don't share much in common with real deployments.
Ok thanks, on it.
cc:
Change:
}, }, }, <del> "spec.jobTemplate.spec.template.spec.restartPolicy: Unsupported value": { </del> <ins> "spec.jobTemplate.spec.template.spec.restartPolicy: Required value": { </ins> ObjectMeta: metav1.ObjectMeta{ Name:      "mycronjob", Namespace: metav1.NamespaceDefault,

Discussion:
<!-- 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: Deployed an cronJob with an empty and it defaulted to which is an invalid option: Leaving the key out completely has the same result What you expected to happen: The empty key to default to something valid like or . Also document what this default is, my proposal would be to have as default since some tasks can't be reran easily. But it might be nice to force as default to enforce the stateless mindset even for crons :) How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: I guess not but I am open for questions :) Environment: Kubernetes version (use ): 1.19.2
My guess would be /sig api-machinery If it is better practice to wait for the triage instead of guessing the sig, let me know :+1:
/sig api-machinery
/assign
/remove-sig api-machinery /sig apps
/assign
/triage accepted
Change:
klog.V(2).Infof("%s: watch of %v returned 429 - backing off", r.name, r.expectedTypeName) <-r.initConnBackoffManager.Backoff().C() continue <ins> case apierrors.IsInternalError(err) && retry.ShouldRetry(): klog.V(2).Infof("%s: retrying watch of %v internal error: %v", r.name, r.expectedTypeName, err) continue </ins> default: klog.Warningf("%s: watch of %v ended with: %v", r.name, r.expectedTypeName, err) }

Discussion:
When etcd is unable to elect leader for 3 election cycles, etcd returns "no leader" error through watches. This can be seen in api-server logs as . Also, when apiserver receives this error, it terminates all watchers: . In large clusters, this can destabilize master, as all these watchers need to be recreated almost at the same time, overwhelming api-server quite often. I propose adding new api-server flag that allows to specify timeout, during which we are retrying to reestablish apiserver <-etcd watches, without terminating all api-server watchers. If we are unable to reestablish watches within this specified timeout, we start terminating all watchers. Losing etcd leader for ~2-3s does not destabilize api-server. Trigger prolonged reelection of etcd leader. No response Observed in all kubernetes versions 1.19-1.24 N/A <details</details<details</details<details</details<details</details
/sig scalability /sig api-machinery /priority important-soon
/wg reliability
/assign
/triage accepted
indeed, this is a source of instability. Is this coming from ?
I believe it's coming from this change. As I mentioned, the idea to mitigate it is to add some parameter that will allow us to ignore this error coming from etcd for specific duration without terminating all watchers, for example 10s be default.
With this comment thread in mind: It would probably be cleaner to allow for simply setting the "timeout" as part of WithRequireLeader option (instead of using the constant of 3). But that would require etcd changes, including the API and we want to workaround that in much smaller timeframe. But a comment about how to make that cleaner with some additional context from here would help.
Change:
set = obj.(*apps.StatefulSet) } if set.Status.Replicas != 3 { <del> t.Error("Falied to scale statefulset to 3 replicas") </del> <ins> t.Errorf("set.Status.Replicas = %v; want 3", set.Status.Replicas) </ins> } pods, err := spc.addTerminatingPod(set, 3) if err != nil {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Unit test error message match the conventional Go style: For example: if got, want := set.Status.Replicas, 3; got != want { t.Errorf("set.Status.Replicas = %v; want %v", got, want) }
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig testing
/assign
/reopen
Change:
err := decorated.Do(func() { defer close(executed) if !delegated { <del> t.Fatalf("expected delegated execution") </del> <ins> t.Errorf("expected delegated execution") </ins> } }) if err == nil {

Discussion:
Can we get this fixed ASAP? Thanks!
yep, thanks for reporting , Brendan Burns wrote:
how reproduceable is this? I have some changes that I think will resolve it but I couldn't reproduce locally even when all my cpu's were pretty tied up and using a high GOMAXPROCS.
flakey label process?
the labelling is due to me failing @ github's label interface. Bulk editing labels removes them if any of the selected things have the label sigh Thanks for the quick fix.
Change:
lbStatus, err := az.getServiceLoadBalancerStatus(service, lb) if err != nil { klog.Errorf("getServiceLoadBalancerStatus(%s) failed: %v", serviceName, err) <del> return nil, err </del> <ins> if err != cloudprovider.InstanceNotFound { return nil, err } </ins> } var serviceIP *string

Discussion:
When upgrade cluster to kubernetes 1.20.15 on Azure platform, I still hit "instance not found" error when ensureHostInPool, and this leads to one of the backend pool members missing since then, users have to add the member back manually. Below is the error: The Detected change in list of current cluster nodes should be in size of 90, but actually it only has 89 nodes here. The symptom matches issue and the But the fix may be incomplete. I expected the "instance not found" error will not affect backend pool members management, and it's ignored somewhere in either or (1.20.15) By upgrading the cluster and trigger the VM recreation, and this may not be easy to reproduce, but it indeed happens several times in our environment <details20.15 </details<detailslegacy Azure cloud provider </details
Hi as you previously worked on the similar issue, could you please kindly help take a look? Thank you in advance!
/sig cloud-provider /area provider/azure /priority critical-urgent
20.x is not a supported version. Could you upgrade to latest supported version?
Hi thank you for reply! Do you mean that this could be already fixed in latest version? I'm not sure if my understanding is correct, but if the issue exists in 1.20.x, even latest version does not ignore this error in the specific place.
yes, please upgrade the version to 1.22 or above with out-of-tree cloud provider
Hi sorry, I don't mean AKS by Azure platform, in fact this is a VMware product built upon Azure, is it possible to port the fix to in-tree cloud provider? That would be great if it's doable, if not, or could you please help point out the fix, maybe we could rase a PR for the in-tree cloud provider. Thank you!
We're still on in-tree cloud provider even if it's upgraded to 1.22.
The error we saw is thrown in this code it appears in out-of-tree code, this still could lead to the issue.
/remove-priority critical-urgent please don't set priorities, those are meant to be used by the community members that triage the issue
Sorry, I copied from previous issue.
are you using VMSS, VMAS or standalone VM?
this is our config, sorry, how do I know which kind of it is?

primaryAvailabilitySetName means the cluster is using VMAS. Per the codes , the issue probably still exists. could you help for the fix? /assign
Thank you for confirming! That's what I'm worried about.
/triage accepted
Change:
obj:  &F{}, }, { <ins> data: "{"fj":""}", obj:  &F{}, }, { </ins> // Invalid string data data: "{"fa":123}", obj:  &F{},

Discussion:
I have created the following secret in my cluster. When I add labels to my secret and try to apply it in the cluster I get the following error This also happens when I use or using the go client. Not sure why, but works. I expect that the secret can be updated with the new labels since the is not actually changed. Steps explained above. 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
/sig cli
/assign
/remove-sig cli /sig apps
Change:
# If you update this list, please also update build/BUILD. readonly KUBE_CLIENT_TARGETS=( cmd/kubectl <ins> cmd/kubectl-convert </ins> ) readonly KUBE_CLIENT_BINARIES=("${KUBE_CLIENT_TARGETS[@]##*/}") readonly KUBE_CLIENT_BINARIES_WIN=("${KUBE_CLIENT_BINARIES[@]/%/.exe}")

Discussion:
was removed in 1.20 in favor of a plugin. However, this is not included in release artifacts. The binary is included in release artifacts, and ideally easily installable via kubectl plugin managers like . /sig cli /assign
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This question came up in a docs review of a page referencing () Once this is resolved, please ensure the website is updated to document installation/use of this tool.
/sig release