jiebi/CodeConvo huggingface dataset:
Change:
} } <ins> func TestDeleteNoObjects(t *testing.T) { f, tf, codec := NewAPIFactory() tf.Printer = &testPrinter{} tf.Client = &client.FakeRESTClient{ Codec: codec, Client: client.HTTPClientFunc(func(req *http.Request) (*http.Response, error) { switch p, m := req.URL.Path, req.Method; { case p == "/ns/test/pods" && m == "GET": return &http.Response{StatusCode: 200, Body: objBody(codec, &api.PodList{})}, nil default: t.Fatalf("unexpected request: %#vn%#v", req.URL, req) return nil, nil } }), } buf := bytes.NewBuffer([]byte{}) stderr := bytes.NewBuffer([]byte{}) cmd := f.NewCmdDelete(buf) cmd.SetOutput(stderr) cmd.Flags().String("namespace", "test", "") cmd.Run(cmd, []string{"pods"}) if buf.String() != "" { t.Errorf("unexpected output: %s", buf.String()) } if stderr.String() != "No resources foundn" { t.Errorf("unexpected output: %s", stderr.String()) } } </ins> func TestDeleteMultipleObject(t *testing.T) { pods, svc := testData()

Discussion:
We should support multiple objects on the command line, but, failing that, some kind of error message would be useful. /cc
Fixing, just fixed the equiv in create
Change:
var ( defaultMetricsCollectorConfig = metricsCollectorConfig{ <del> Metrics: []string{ "scheduler_scheduling_algorithm_predicate_evaluation_seconds", "scheduler_scheduling_algorithm_priority_evaluation_seconds", "scheduler_e2e_scheduling_duration_seconds", "scheduler_pod_scheduling_duration_seconds", </del> <ins> Metrics: map[string]*labelValues{ "scheduler_framework_extension_point_duration_seconds": { label:  extensionPointsLabelName, values: []string{"Filter", "Score"}, }, "scheduler_e2e_scheduling_duration_seconds": nil, "scheduler_pod_scheduling_duration_seconds": nil, </ins> }, } )

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : run got the below error message, We should provide the metric data for different extension points from the metric of "schedulerframeworkextensionpointdurationseconds" Why is this needed: Those metrics have been removed by this commit - Those metrics are deprecated cause it is suggested to use - , but simply remove those metrics definitely is not a nice way to address the issue. /sig scheduling
/triage accept
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /triage accept 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
/triage accepted
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
Change:
import ( "fmt" "net/http" <ins> "time" "k8s.io/api/core/v1" </ins> "k8s.io/apimachinery/pkg/util/sets" "k8s.io/kubernetes/pkg/master/ports" "k8s.io/kubernetes/test/e2e/framework"

Discussion:
Augment to turn on session affinity for a service, lookup the vip from a container/node and make sure we only hit a single endpoint with N ready/running endpoints.
This looks like it is still relevant can anyone confirm if we these? I still see a
/assign
Are you working on it? Could you please assign this issue to me and I am happy to fix it. Thanks a lot!
/assign I have it in my "backlog" behind NetworkPolicy stuff. Feel free to take it over if you have time.
GitHub didn't allow me to assign the following users: m1093782566. Note that only can be assigned. <detailsIn response to : /assign 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
Would appreciate :)
/assign
Change:
effect: "NoExecute" - operator: "Exists" effect: "NoSchedule" <del> hostNetwork: true hostPID: true </del> volumes: - name: device-plugin hostPath:

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?: /kind feature What happened: Host Networking is enabled for the nvidia-gpu daemonset. Trying to understand the purpose. What you expected to happen: Disabling hostNetworking seemed to work and GPU workloads are able to be scheduled to the cluster. How to reproduce it (as minimally and precisely as possible): Remove this line and apply the daemonset to a GPU enabled cluster. Anything else we need to know?: I would like to understand the purpose for using hostNetworking for the nvidia-gpu daemonset. It appears nvidia implementation does not use it either:
/sig node /sig network
Change:
LogSSHResult(result) if result.Code != 0 || err != nil { <del> return nil, fmt.Errorf("failed running %q: %v (exit code %d)", cmd, err, result.Code) </del> <ins> return nil, fmt.Errorf("failed running %q: %v (exit code %d, stderr %v)", cmd, err, result.Code, result.Stderr) </ins> } return &result, nil

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: e2e test "[sig-network] Network [It] should set TCP CLOSEWAIT timeout" requires the test target OS supports /proc/net/nfconntrack, but Ubuntu 16.04 doesn't support it. Then the test fails today like the following: What you expected to happen: The test succeeded or was skipped. How to reproduce it (as minimally and precisely as possible): Just kick Anything else we need to know?: The existence of /proc/net/nfconntrack depends on the Linux kernel config CONFIGNFCONNTRACKPROCFS, but that is disabled on Ubuntu 16.04. In addition, the test is skipped if the node number is less than 2. So I guess that is one of reasons this issue was not present until today. Environment: Kubernetes version (use ): v1.11.3 Cloud provider or hardware configuration: OpenStack OS (e.g. from /etc/os-release): Ubuntu 16.04.4 LTS Kernel (e.g. ): 4.4.0-134-generic Install tools: kubeadm Others:
/sig network
Some kube-proxy functionalities depends on conntrack, is it possible to run a conformance cluster without having conntrack enable?
Change:
} func (ds *dockerService) performPlatformSpecificContainerForContainer(containerID string) (errors []error) { <del> if cleanupInfo, present := ds.containerCleanupInfos[containerID]; present { </del> <ins> if cleanupInfo, present := ds.getContainerCleanupInfo(containerID); present { </ins> errors = ds.performPlatformSpecificContainerCleanupAndLogErrors(containerID, cleanupInfo) if len(errors) == 0 { <del> delete(ds.containerCleanupInfos, containerID) </del> <ins> ds.clearContainerCleanupInfo(containerID) </ins> } }

Discussion:
What happened: Windows kubelet panic occasionally on nodes which have high volume of pods run and delete. Full logs: Preliminary investigate result: How to reproduce it (as minimally and precisely as possible): Run high volume of pods and delete them when they completed in Windows nodes. Environment: Kubernetes version (use ): 1.17.7 Cloud provider or hardware configuration: Azure AKS OS (e.g: ): Windows Server 2019 Kernel (e.g. ): 10.0..1282
/assign I would like to give this a shot.
/remove-sig windows I think this is not a windows specific problem. /sig node /area kubelet
Hi! Thanks for your report, I have filed to address this issue.
This issue is a bit urgent for our situation, it occurs every few days in production clusters. Seems the PR is pending a few days, is it possible to increase the priority to merge it trunk and 1.17/1.18 branch? Thanks
I understand how urgent this issue is, but I am not privileged to do anything further :(
Do you know anyone who can help?
looks like a simple fix, add a lock for , I could help.
There is already a fix by , the problem is the PR is pending, not sure if you or someone can increase the priority to merge it trunk and 1.17/1.18 branch asap. Our AKS clusters are affecting by this frequently.
Thanks guys.
Change:
printLabelsMultilineWithIndent(w, "  ", "Labels", "t", pvc.Labels, sets.NewString()) printLabelsMultilineWithIndent(w, "  ", "Annotations", "t", pvc.Annotations, sets.NewString()) if capacity, ok := pvc.Spec.Resources.Requests[api.ResourceStorage]; ok { <del> w.Write(LEVEL_1, "Capacity:t%sn", capacity) </del> <ins> w.Write(LEVEL_1, "Capacity:t%sn", capacity.String()) </ins> } else { w.Write(LEVEL_1, "Capacity:t%sn", "<default>") }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): Bug Kubernetes version (use ): master branch What happened: Here's the output when we print as string. What you expected to happen: print How to reproduce it (as minimally and precisely as possible): /assign
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig api-machinery
/king bug
Here's the output I get with with a test PVC: and :
Ditto, not seeing a repro against master head:
please try :).
Ah, brainfart, I thought this was complaining about . Yes, indeed is returning: This should be fixed for 1.7.
Will let add approved-for-milestone
I'm assuming you're working on this?
, yes, the PR is here, waiting for 1.7 milestone to merge :).
, thanks for your verification :). I updated title to include "statefulset".
Change:
**-bindaddress**="0.0.0.0" The address for the proxy server to serve on (set to 0.0.0.0 or "" for all interfaces) <del> **-configfile**="/tmp/proxy_config" Configuration file for the proxy </del> **-etcd_servers**=[] List of etcd servers to watch (http://ip:port), comma separated (optional)

Discussion:
It's not well tested nor widely used; so it should either be removed or have tests and uses .
Change:
command := exec.Command(mountCmd, mountArgs...) output, err := command.CombinedOutput() if err != nil { <ins> if err.Error() == errNoChildProcesses { if command.ProcessState.Success() { // We don't consider errNoChildProcesses an error if the process itself succeeded (see - k/k issue #103753). return nil } // Rewrite err with the actual exit error of the process. err = &exec.ExitError{ProcessState: command.ProcessState} } </ins> klog.Errorf("Mount failed: %vnMounting command: %snMounting arguments: %snOutput: %sn", err, mountCmd, mountArgsLogStr, string(output)) return fmt.Errorf("mount failed: %vnMounting command: %snMounting arguments: %snOutput: %s", err, mountCmd, mountArgsLogStr, string(output))

Discussion:
While investigating some slowness in mounting/unmounting operations of PVs (in this case EFS volumes) for pods, we observed errors like these: fortunately it does recover quickly on Kubelet’s next retry: Looking through the Kubelet code I found out that the issue is not related to the umount calls themselves, but rather a race condition inside where we call umount. Because of the way golang’s function (called inside ) is implemented, it for the child process to finish after it is . Since there isn't any locking on the child process across those function calls, it's possible that the child process exits event before the Wait() call starts. In such case the wait call returns with a error (). This error is more likely to happen especially if the gap between the Start() and Wait() calls is more (which could for e,g happen if the goroutine had CPU cycles snatched away from it for some time in between those calls). A similar issue also exists in the . While this is a self-recovering issue (because of Kubelet retries), it does seem to increase the pod startup/cleanup latency upto a 1s. Open to suggestions for a fix. The simplest one occurring to me is to treat the error as a special one on which we don't actually return an error for the mount/unmount calls. /sig storage /sig scalability /assign
Another thing is when analyzing a distribution of such errors across different nodes, we observed a skew. The top 10% of the nodes were seeing more than 90% of these errors. And these are nodes that are running hotter (w.r.t the pod churn) compared to others: ! Given this, I'm wondering if those errors are higher on those nodes just because of statistical significance or other causes like more GC pauses happening on those nodes.
/triage accepted
^ I've opened this PR to fix the Mount/Unmount functions in the file. In general we might want to make a similar fix to other invocations of exec.Run() and exec.CombinedOutput() within our codebase. But that'll be a bigger change. Happy to open another issue for it.
Sorry for opening the PR against wrong repo, here's the right one -
Change:
} func (m *ManagerImpl) deviceHasTopologyAlignment(resource string) bool { <del> // If any device has Topology set, we assume they care about alignment. for device := range m.allDevices[resource] { if m.allDevices[resource][device].Topology != nil { </del> <ins> // If any device has Topology NUMANodes available, we assume they care about alignment. for _, device := range m.allDevices[resource] { if device.Topology != nil && len(device.Topology.Nodes) > 0 { </ins> return true } }

Discussion:
A node with: fails a pod that uses device plugin resources (empty but non-nil ) : Our device plugin sends the following registration: So we send an empty which is interpreted as "no possible NUMA affinities": How is this different from value? I can workaround the problem by sending but it's not how this is supposed to work. Can the two if's combined or should we updated the documentation? My environment: a single-node k8s cluster w/ device plugin that does The node needs to run two kinds of pods: those that need/use topology single-numa-node and pods that just use a device plugin resources that does not provide topologyhints. <details</details<detailsN/A (kubeadm single node cluster) </details<details</details<detailskubeadm </details<detailscontainerd </details<detailsintel SGX device plugin v0.24 </details
/cc
It's possible that better documentation is needed, but we could also probably do more to handle this better in the device plugin. The implementation you pointed out above relies on depicting "don't care" and depicting "I tried but couldn't generate any hints that provide alignment". One could argue though that should have generated a set of hints and not a . I would need to look at the code again to know for sure if this makes sense or not though.
This interpretation makes sense but Right, if the hint provider fails to provide hints, I guess the pod should not be blamed (by not making it to run) for that. /sig node
/triage accepted /priority backlog
/cc
I can at least help with the documentation part if we decide that it alone needs changing.
I'm reviewing this area for other reasons, we should indeed calrify the hint API expectations. Up until now my rule of thumb was pretty much "what cpumanager does" which has room for improvement.
This could be isolated to only by returning when : when running is pointless, IMO
Submitted a
The corresponding documentation update:
Change:
return } pod := podInfo.Pod <del> if pod.DeletionTimestamp != nil { sched.Recorder.Eventf(pod, nil, v1.EventTypeWarning, "FailedScheduling", "Scheduling", "skip schedule deleting pod: %v/%v", pod.Namespace, pod.Name) klog.V(3).Infof("Skip schedule deleting pod: %v/%v", pod.Namespace, pod.Name) </del> <ins> if sched.skipPodSchedule(pod) { </ins> return }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Similar problem as , howerver in our case, pod's annotation was updated at scheduling cycle, so it had not been assumed when its annotation was updated. We also need to deal with this case. Detailed steps: a pod . tried to schedule the pod. Then it was prediated by a filter plugin that we write. This plugin modified the pod's annotation to record something. Because pod's annotation changed, scheduuler received a pod update event, and put the pod to the schedule queue again. scheduled the pod successfully for this schedule cycle. tried to schedule the updated pod again(it was put to the schedule queue at step 2). If the pod was scheduled sucessfully, we would see the error log() in scheduler. If scheduler failed to schedue the pod, scheduler would send a failed scheduler event to pod. They are both confusing because the pod had already been successfully. ! Why is this needed: It will be better to handle pod annotation updates during scheduling more gracefully. /kind cleanup /sig scheduling /assign
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : <!-- Please only use this template for submitting enhancement requests --1. Created a pod . Scheduler tried to schedule the pod. Then it was prediated by a filter plugin that we write. This plugin modified the pod's annotation to record something. Because pod's annotation changed, scheduuler received a pod update event, and put the pod to the schedule queue again. Scheduler scheduled the pod successfully for this schedule cycle. Scheduler tried to schedule the updated pod again(it was put to the schedule queue at step 2). If the pod was scheduled sucessfully, we would see the error log() in scheduler. If scheduler failed to schedue the pod, scheduler would send a failed scheduler event to pod. They are both confusing because the pod had already been successfully. /sig scheduler /assign 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:
expectedMaxVolumePerNode   int64 expectedAccessibleTopology map[string]string mustFail                   bool <ins> mustTimeout                bool </ins> err                        error }{ {

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: Kubelet dies with a panic exception if CSI plugin returns NodeId == "" and nil error. Exception log see at the end of the message What you expected to happen: Kubelet should just raise an error to the plugin and ignore the registration. How to reproduce it (as minimally and precisely as possible): Create a CSI plugin with only Node that would implement GetNodeInfo as follows: Register it as a DaemonSet and see kublet crush Anything else we need to know?: Environment: Kubernetes version (use ): 1.14.10-gke.17 Cloud provider or hardware configuration: GKE OS (e.g: ): Container-Optimized OS (cos) Kernel (e.g. ): - Install tools: Network plugin and version (if this is a network-related bug): Others: Related exception Related line of code: - no check whether error is not nil before calling Error() on it.
/sig storage
/sig node is this the version of the kubelet too? 14 is out of support. is the issue reproducible with a 1.15+ kubelet?
/assign
I checked the code - same defect still exists in current codebase.
thanks /priority important-soon
Wow, that was fast. Thanks!
Change:
}), expected: v1.PodQOSBestEffort, }, <ins> { pod: newPodWithInitContainers("init-container", []v1.Container{ newContainer("best-effort", getResourceList("", ""), getResourceList("", "")), }, []v1.Container{ newContainer("burstable", getResourceList("10m", "100Mi"), getResourceList("100m", "200Mi")), }), expected: v1.PodQOSBurstable, }, </ins> } for id, testCase := range testCases { if actual := GetPodQOS(testCase.pod); testCase.expected != actual {

Discussion:
What happened: A pod that has init container with request for cpu and memory, and containers that make no request for cpu or memory reports a BestEffort QoS class. This is incorrect. What you expected to happen: Containers that make requests independent of lifecycle phase should impact quality of service calculation. Found in 1.12, looks to still be present in 1.14 dev. /cc
/priority important-soon
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/lifecycle frozen
I think this doesn't work very well with the current cpu manager logic. The problem is that a pod can't now have QoS class Guaranteed if it has init containers which don't have matching requests/limits. This means that normal containers in such a pod don't then get dedicated cpus even though the init containers are long gone when the app containers (with matching requests/limits) are finally started. This is quite non-intuitive. I would propose separating at least Guaranteed class calculation so that the init container resource requests wouldn't affect the calculation. What do you think?
Change:
return err } <ins> // Returns first external ip of the node or "<none>" if none is found. func getNodeExternalIP(node *api.Node) string { for _, address := range node.Status.Addresses { if address.Type == api.NodeExternalIP { return address.Address } } return "<none>" } </ins> func printNodeList(list *api.NodeList, w io.Writer, options PrintOptions) error { for _, node := range list.Items { if err := printNode(&node, w, options); err != nil {

Discussion:
Nice to have for nodePort service debugging, creating manual firewalls, hitting hostNetwork or hostPort pods etc. Currently I need to either -o yaml, --template, or switch to gcloud.
This should be quite easy, should be good for contribution.
I could take a look at this. What information exactly that is available in yaml output should be shown? This is example yaml from my node: There should be an additional address with type , right? Should all types be supported or only external when is used?
-o wide should just dump what we get from the api-server right? What changes should be in kubectl?
-o yaml dumps apiserver outout, -o wide appends useful information at the cost of overflowing 80 chars. I'm asking that -o wide does for nodes what it already does for pods. I currently have such a function in my bash rc: I use it pretty often. That's a signal that more people are probably doing the same.
thanks!