jiebi/CodeConvo huggingface dataset:
Change:
framework.ExpectNoError(err, "Unable to re-create the deleted node") framework.ExpectNoError(framework.WaitForGroupSize(framework.TestContext.CloudConfig.NodeInstanceGroup, int32(initialGroupSize)), "Unable to get the node group back to the original size") framework.WaitForNodeToBeReady(f.ClientSet, nodeToDelete.Name, nodeStatusTimeout) <ins> framework.WaitForAllNodesSchedulable(f.ClientSet, nodeStatusTimeout) </ins> nodes = framework.GetReadySchedulableNodesOrDie(f.ClientSet) <del> if len(nodes.Items) != originalCount { return fmt.Errorf("The node count is not back to original count") } return nil </del> <ins> Expect(len(nodes.Items)).To(Equal(originalCount), "Requires node count to return to original node count.") </ins> }() By("submitting host0Pod to kubernetes")

Discussion:
Since 2 days ago, the test is becoming more and more flaky, and one of the examples is: https://k8s-
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
please triage this one. Currently I put it as the release blocker, and please feel free to remove that if you think it is not. Thanks!
The test deletes the node, and at the end, waits 5 minutes for the node to become ready, but it timed out. cc
The test logic hasn't changed after I last modified it, so the test deletes the node through gcloud, and the instance should be restarted automatically by GCE because it's part of an instance template. The likely possibility, as pointed out, is that another change made node discovery take longer, so extending the timeout would be enough. The very unlikely possibility is there's a problem discovering brand new instances.
Change:
if !reflect.DeepEqual(n.podCIDRs, podCIDRs) { klog.ErrorS(nil, "Using NodeCIDR LocalDetector mode, current PodCIDRs are different than previous PodCIDRs, restarting", "node", klog.KObj(node), "newPodCIDRs", podCIDRs, "oldPodCIDRs", n.podCIDRs) <del> panic("Current Node PodCIDRs are different than previous PodCIDRs, restarting") </del> <ins> klog.FlushAndExit(klog.ExitFlushTimeout, 1) </ins> } }

Discussion:
There are some cases when kube-proxy has to exit and restart, in order to do that we panic, but this has the problem that the log output shows a literal "panic" message and engineers, support, customers and automation gets confused, thinking that is a problem when is the expected behavior. As suggested by in , we can replace by /sig network /help /kind cleanup
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : There are some cases when kube-proxy has to exit and restart, in order to do that we panic, but this has the problem that the log output shows a literal "panic" message and engineers, support, customers and automation gets confused, thinking that is a problem when is the expected behavior. /help /kind cleanup </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
/assign I would like to raise a PR to fix this.
Change:
# Restart the kube-apiserver on a node ($1) function restart-apiserver { <del> ssh-to-node "$1" "sudo /etc/init.d/kube-apiserver restart" </del> <ins> ssh-to-node "$1" "sudo docker kill `sudo docker ps | grep /kube-apiserver | awk '{print $1}'`" </ins> } # Perform preparations required to run e2e tests

Discussion:
Now that kube-apiserver runs in a container, no longer exists: /cc
Actually fixed by .
Change:
func sshRestartMaster() error { if !ProviderIs("gce", "aws") { <del> return fmt.Errorf("unsupported provider: %s", TestContext.Provider) </del> <ins> return fmt.Errorf("unsupported provider for sshRestartMaster: %s", TestContext.Provider) </ins> } var command string if ProviderIs("gce") {

Discussion:
is failing with "framework.RestartControllerManager() = unsupported provider: gke; want nil" /kind failing-test
/sig network
Introduced in , should be fixed by
Change:
nodeAllocatableMilliCPU2, nodeAvailableMilliCPU2 := getNodeAllocatableAndAvailableMilliCPUValues(&node) framework.Logf("TEST2: Node '%s': NodeAllocatable MilliCPUs = %dm. MilliCPUs currently available to allocate = %dm.", node.Name, nodeAllocatableMilliCPU2, nodeAvailableMilliCPU2) <del> testPod3CPUQuantity := resource.NewMilliQuantity(nodeAvailableMilliCPU2+testPod1CPUQuantity.MilliValue()/2, resource.DecimalSI) </del> <ins> testPod3CPUQuantity := resource.NewMilliQuantity(nodeAvailableMilliCPU2+testPod1CPUQuantity.MilliValue()/4, resource.DecimalSI) </ins> testPod1CPUQuantityResized := resource.NewMilliQuantity(testPod1CPUQuantity.MilliValue()/3, resource.DecimalSI) framework.Logf("TEST2: testPod1 MilliCPUs after resize '%dm'", testPod1CPUQuantityResized.MilliValue())

Discussion:
/kind failing-test /sig node
/assign
/triage accepted
Seems to me that problem is related with test-infra config ? I noticed Checking kubelet logs there are complains about kubelet not finding configuration file. Even if this job run in AWS it is defined under ( ) and not under aws subfolder. Performing vimdiff periodic- ./aws/periodic-eks- i notice some variables are missing, but i don't have permissions to re-run the job to be able to debug more on this. Test code for InPlacePodVerticalScaling doesn't seem to be the root cause here, if we could increase the kubelet log level and perform a rerun might be helpful to debug more. Checking containerd logs , it seems that a container failed to stop, this might explain why pod resize failed due to lack of resources)
These two tests are permanent failing on this job
True, but looking deeper it seems for the first test it fails ( unable to resize there are no available resources ) because a previous pod has not been deleted according to containerd logs . For second error it seems to be a config error , it complains that it could not login. I believe something is wrong with the setup ( repeated kubelet config errors in kubelet logs )
/sig storage
More information for the container delete error, it belongs to mainpod-with-poststart-http-hookrestartable-init-container-lifecycle-hook. I will try to check if InPlacePodVerticalScaling test can be improved to cover this corner case. Please note, Garbage collect error happens before the InPlacePodVerticalScaling test failure, perhaps this is the root cause of the failure in InPlacePodVerticalScaling error. Perhaps we should update Issue title and include the garbage collect error for this issue? ! Source: / . Please search for
Change:
epIpt := netlinktest.ExpectedIptablesChain{ string(kubeServicesChain): {{ JumpChain: string(KubeLoadBalancerChain), MatchSet: kubeLoadBalancerSet, <ins> }, { JumpChain: string(KubeMarkMasqChain), MatchSet: kubeClusterIPSet, }, { JumpChain: string(KubeNodePortChain), MatchSet: "", }, { JumpChain: "ACCEPT", MatchSet: kubeClusterIPSet, }, { JumpChain: "ACCEPT", MatchSet: kubeLoadBalancerSet, </ins> }}, string(KubeLoadBalancerChain): {{ JumpChain: string(KubeFireWallChain), MatchSet: kubeLoadbalancerFWSet,

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 --ipvs mode didn't preserve client IP for NodePort Service with protocol SCTP and ExternalTrafficPolicy Local. iptables mode works fine. ipvs mode with TCP and UDP protocol works fine. Client IP for NodePort Service should be preseved when ExternalTrafficPolicy is Local regardless of the mode and the protocol. kube-proxy mode to ipvs a NodePort service with protocol SCTP and ExternalTrafficPolicy Local the NodePort service, the client IP was not preserved This is caused by wrong order of iptables rules that match kubeNodePortLocalSetSCTP and kubeNodePortSetSCTP: Kubernetes version (use ): v1.22.0 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:
/sig network /assign
/triage accepted
Change:
{ name: "A pod has a toleration that keys and values match the taint on the node, but (non-empty) effect doesn't match, " + "can't be scheduled onto the node", <del> pod:        podWithTolerations("pod1", []v1.Toleration{{Key: "foo", Operator: "Equal", Value: "bar", Effect: "PreferNoSchedule"}}), node:       nodeWithTaints("nodeA", []v1.Taint{{Key: "foo", Value: "bar", Effect: "NoSchedule"}}), wantStatus: unschedulable, </del> <ins> pod:  podWithTolerations("pod1", []v1.Toleration{{Key: "foo", Operator: "Equal", Value: "bar", Effect: "PreferNoSchedule"}}), node: nodeWithTaints("nodeA", []v1.Taint{{Key: "foo", Value: "bar", Effect: "NoSchedule"}}), wantStatus: framework.NewStatus(framework.UnschedulableAndUnresolvable, "node(s) had taint {foo: bar}, that the pod didn't tolerate"), </ins> }, { name: "The pod has a toleration that keys and values match the taint on the node, the effect of toleration is empty, " +

Discussion:
When trying to see why pods don't start using either kubectl get events or kubectl describe pod , the base message is not detailed enough. Warning FailedScheduling 5s (x4 over 65s) default-scheduler 0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate. What would you like to be : Details of the taint and details of what it didn't tolerate Why is this needed: To get much much better debug information by default when trying to understand why pods can't launch.
/sig cli
/sig scheduling /priority important-longterm
/cc
/remove-sig cli
Those labels are not set on the issue: <detailsIn response to : /remove-sig cli </details
/good-first-issue
/assign starizard
Can I get an idea of what this would involve? I might be able to put some work on it.
I assume is taking this already. The error message is produced in We probably also require changes in to get the name of the missing toleration.
/remove-help
Change:
} var wg sync.WaitGroup wg.Add(1) <del> go func(volSpec *volume.Spec, expectAttach bool) { attachID, err := csiAttacher.Attach(volSpec, types.NodeName("fakeNode")) </del> <ins> go func(volSpec *volume.Spec) { attachID, err := csiAttacher.Attach(volSpec, "fakeNode") </ins> defer wg.Done() if err != nil {

Discussion:
Which test(s) are flaking: TestAttacherWithCSIDriver Reason for failure: This is flaking rarely enough that it is not caught by our CI jobs, which currently tolerate up to 2 unit test failures per run (!). With that toleration removed in , this flake has been seen (). Reproducible with the following steps: a test binary for the affected package: the affected test using the tool (setting the timeout to a generous timeout relative to the normal test runtime of .02 seconds): failures are seen, look at the logs to see the details about the error: /sig storage cc
/assign can you help investigate this flake?
I have found the root cause. /assign
filed to address this issue.
Change:
} itArg := testArg It(name, func() { <ins> uuid := string(util.NewUUID()) </ins> totalPods := itArg.podsPerMinion * minionCount <del> RCName = "my-hostname-density" + strconv.Itoa(totalPods) + "-" + string(util.NewUUID()) </del> <ins> nameStr := strconv.Itoa(totalPods) + "-" + uuid ns = "e2e-density" + nameStr RCName = "my-hostname-density" + nameStr // Create a listener for events events := make([](*api.Event), 0) _, controller := framework.NewInformer( &cache.ListWatch{ ListFunc: func() (runtime.Object, error) { return c.Events(ns).List(labels.Everything(), fields.Everything()) }, WatchFunc: func(rv string) (watch.Interface, error) { return c.Events(ns).Watch(labels.Everything(), fields.Everything(), rv) }, }, &api.Event{}, time.Second*10, framework.ResourceEventHandlerFuncs{ AddFunc: func(obj interface{}) { events = append(events, obj.(*api.Event)) }, }, ) stop := make(chan struct{}) go controller.Run(stop) // Start the replication controller </ins> RunRC(c, RCName, ns, "gcr.io/google_containers/pause:go", totalPods) <ins> By("Waiting for all events to be recorded") last := -1 current := len(events) timeout := 10 * time.Minute for start := time.Now(); last < current && time.Since(start) < timeout; time.Sleep(10 * time.Second) { last = current current = len(events) } close(stop) if current != last { Logf("Warning: Not all events were recorded after waiting %.2f minutes", timeout.Minutes()) } Logf("Found %d events", current) // Verify there were no pod killings or failures By("Verifying there were no pod killings or failures") for _, e := range events { for _, s := range []string{"kill", "fail"} { Expect(e.Reason).NotTo(ContainSubstring(s), "event:' %s', reason: '%s', message: '%s', field path: '%s'", e, e.ObjectMeta.Name, e.Message, e.InvolvedObject.FieldPath) } } </ins> }) }

Discussion:
Currently the density tests are ok if all the pods come up eventually. We should verify there are no failure/error events while the pods are coming up. This could indicate issues dealing with the number of pods and should be investigated.
has been merged, and there's already an issue filed for followup actions, so I think we can close this.
Change:
pathOptions.EnvVar = "" streams, _, buf, _ := genericclioptions.NewTestIOStreams() cmd := NewCmdConfigView(cmdutil.NewFactory(genericclioptions.NewTestConfigFlags()), streams, pathOptions) <ins> // "context" is a global flag, inherited from base kubectl command in the real world cmd.Flags().String("context", "", "The name of the kubeconfig context to use") </ins> cmd.Flags().Parse(test.flags) if err := cmd.Execute(); err != nil { t.Fatalf("unexpected error executing command: %v,kubectl config view flags: %v", err, test.flags) }

Discussion:
/kind bug What happened: Current context was set to cluster1. Ran and got back information about cluster1 instead. What you expected to happen: I expected the output to be the cluster2 information How to reproduce it (as minimally and precisely as possible): Have two contexts in your kube config, A and B Run to set A as current context Run Anything else we need to know?: I'd like to help contribute, so if this is an easy fix, someone point me in the right direction and I'll try to get it done. Environment: Kubernetes version (use ): 1.10.2 OS (e.g. from /etc/os-release): MacOS 10.11.6 Install tools: kubectl was installed via brew
Reiterating the mentions to trigger a notification: <detailsIn response to : Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign Filed
Change:
} } } <ins> func TestConvertSliceStringToDeletionPropagation(t *testing.T) { tcs := []struct { Input  []string Output v1.DeletionPropagation }{ { Input:  nil, Output: "", }, { Input:  []string{}, Output: "", }, { Input:  []string{"foo"}, Output: "foo", }, { Input:  []string{"bar", "foo"}, Output: "bar", }, } for _, tc := range tcs { var dp v1.DeletionPropagation if err := v1.Convert_Slice_string_To_v1_DeletionPropagation(&tc.Input, &dp, nil); err != nil { t.Errorf("Convert_Slice_string_To_v1_DeletionPropagation(%#v): %v", tc.Input, err) continue } if !apiequality.Semantic.DeepEqual(dp, tc.Output) { t.Errorf("slice string to DeletionPropagation conversion failed: got %v; want %v", dp, tc.Output) } } } </ins>

Discussion:
makes API server accepts DeleteOptions as a query parameter, but APIserver cannot parse , which is a new field in 1.6. Probably it's a bug in the parameterCodec. cc
IMO this is not a 1.6 release blocker
does this apply to all DeleteOptions fields? does a 1.5 server handle the orphanDependents field sent by correctly?
No, is handled correctly by the apiserver built from head. And for , because our generated clients still encode DeleteOptions as body, so they are not affected.
- we can close this one right?
/sig api-machinery
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. Prevent issues from auto-closing with an comment. 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 /remove-lifecycle stale
Why was this closed? I'm using a Kubernetes 1.9 cluster and this is still an issue. If I pass propagationPolicy as part of the query string (as per the documentation), I still receive the same error message. If I pass a DeleteOptions object with the propagationPolicy within, it works.
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
what documentation were you referring to? Is it the openapi doc? I don't know if we can just deprecate the support of query parameters for DELETE. I understand it's a breaking change, but it has been broken for a year.
Everything in delete needs to be moved to query parameters (unfortunately) as it is apparently non-standard to have a body in a delete request.

Chao Xu <:
/reopen
/remove-lifecycle rotten
cc
/assign
The DELETE operation states that propagationPolicy is a query parameter. Is correct that it's non-standard to have a body on a delete request.
GKE default version is still 1.9.7
Change:
# We do this in a tmpdir in case the dest has other non-autogenned files # We don't want to include them in the list of gen'd files local tmpdir="${KUBE_ROOT}/doc_tmp" <del> mkdir "${tmpdir}" </del> <ins> mkdir -p "${tmpdir}" </ins> # generate the new files ${cmd} "${tmpdir}" # create the list of generated files

Discussion:
Multiple, for example: Since See above The test tolerations are now to strict: 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
I think it's from if you check the cri-o versions the succeessful one was and the failing was
Working on a fix in
cc
/reopen need to bump in kube as well to fully get the fix
Reopened this issue. <detailsIn response to : /reopen </details
Change:
# See the License for the specific language governing permissions and # limitations under the License. <del> # Set provider independent environment variables </del> <ins> # Set the default provider of Kubernetes cluster to know where to load provider-specific scripts # You can override the default provider by exporting the KUBERNETES_PROVIDER # variable in your bashrc # # The valid values: 'gce', 'azure' and 'vagrant' </ins> <del> # Set provider of Kubernetes cluster to know where to load provider-specific scripts, values: gce, vagrant, etc. KUBERNETES_PROVIDER="gce" #KUBERNETES_PROVIDER="vagrant" </del> <ins> KUBERNETES_PROVIDER=${KUBERNETES_PROVIDER:-gce} </ins>

Discussion:
Creating a service with fails to be created when trying to use a TCP health probe. Example service: Failed as follows: Health probe works correctly and is registered properly as TCP health probe. Take the mentioned service yaml and apply it, together with a corresponding pod / deployment exposing port 445. E.g. like this: The respective code seems to take the wrong path to me (it's +/- the same code on the in-tree as on the out of tree cloud provider): My reading of the code and passed values are like this: returns returns -- because returns returns therefore: So the requestPath is not at this point and the azure API server returns a 400 bad request. Kubernetes version (use ): 1.20.6 Cloud provider or hardware configuration: azure OS (e.g: ): linux Network plugin and version (if this is a network-related bug): vxlan & flannel
/sig cloud-provider
related PR introducing the feature:
/assign /triage accepted
/assign
Change:
return &http.Response{StatusCode: 200, Header: cmdtesting.DefaultHeader(), Body: cmdtesting.ObjBody(codec, newNode)}, nil case m.isFor("DELETE", "/namespaces/default/pods/bar"): atomic.AddInt32(&deletions, 1) <ins> if test.failUponEvictionOrDeletion { return nil, errors.New("request failed") } </ins> return &http.Response{StatusCode: 204, Header: cmdtesting.DefaultHeader(), Body: cmdtesting.ObjBody(codec, &test.pods[0])}, nil case m.isFor("POST", "/namespaces/default/pods/bar/eviction"): atomic.AddInt32(&evictions, 1) <ins> if test.failUponEvictionOrDeletion { return nil, errors.New("request failed") } </ins> return &http.Response{StatusCode: 201, Header: cmdtesting.DefaultHeader(), Body: cmdtesting.ObjBody(codec, &policyv1beta1.Eviction{})}, nil default: t.Fatalf("%s: unexpected request: %v %#vn%#v", test.description, req.Method, req.URL, req)

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: kubectl drain crashed with panic when apiserver connection disappeared while there were pods that couldn't be evicted/deleted (sorry, the problem is a bit hard to reproduce and the log was lost) What you expected to happen: kubectl drain should exit with a proper error message How to reproduce it (as minimally and precisely as possible): Try kubectl drain multiple times, interrupting the connection during eviction/deletion Anything else we need to know?: The here can be in case if returns an error, and will panic upon accessing : This causes the c Environment: Kubernetes version (use ): The problem is present as of but is also present in earlier versions (I have a fix for this bug)
/priority important-longterm /sig cli