jiebi/CodeConvo huggingface dataset:
Code change:
return threadsPerCore > 1 } <ins> func isMultiNUMA() bool { outData, err := exec.Command("/bin/sh", "-c", "lscpu | grep "NUMA node(s):" | cut -d ":" -f 2").Output() framework.ExpectNoError(err) numaNodes, err := strconv.Atoi(strings.TrimSpace(string(outData))) framework.ExpectNoError(err) return numaNodes > 1 } </ins> func getCPUSiblingList(cpuRes int64) string { out, err := exec.Command("/bin/sh", "-c", fmt.Sprintf("cat /sys/devices/system/cpu/cpu%d/topology/thread_siblings_list | tr -d "nr"", cpuRes)).Output() framework.ExpectNoError(err) return string(out) } <ins> func getCoreSiblingList(cpuRes int64) string { out, err := exec.Command("/bin/sh", "-c", fmt.Sprintf("cat /sys/devices/system/cpu/cpu%d/topology/core_siblings_list | tr -d "nr"", cpuRes)).Output() framework.ExpectNoError(err) return string(out) } </ins> func deleteStateFile() { err := exec.Command("/bin/sh", "-c", "rm -f /var/lib/kubelet/cpu_manager_state").Run() framework.ExpectNoError(err, "error deleting state file")

Related discussion:
text: Which jobs are failing: N/A - AFAICT CI jobs works fine Which test(s) are failing: Since when has it been failing: no historical record on CI Testgrid link: N/A Reason for failure: I believe the tests make too many assumptions around the hardware, and the code is actually OK. to be confirmed. Anything else we need to know:
/sig node /sig testing
also affects the recently topology manager e2e tests. My PR uses a different approach to check resource alignment so is not affected. /cc
I'll work on a PR to fix this issue ASAP
Thanks for opening this issue. We knew about this, just had not opened an issue to track it, so thanks for doing that! Deepthi has been looing at CPU Manager tests, not sure if she has some PR in progress or not. I'll make sure to forward this to her (can find her user id here ....) in case she has something in progress
Code change:
}) } <del> // Wait for a job to not exist by listing jobs explicitly. func waitForJobNotExist(c clientset.Interface, ns string, targetJob *batchv1.Job) error { </del> <ins> // Wait for a job to disappear by listing them explicitly. func waitForJobToDisappear(c clientset.Interface, ns string, targetJob *batchv1.Job) error { </ins> return wait.Poll(framework.Poll, cronJobTimeout, func() (bool, error) { jobs, err := c.BatchV1().Jobs(ns).List(metav1.ListOptions{}) if err != nil {

Related discussion:
text: What happened: There seems to be a regression after 1.13 release. A Cronjob with default settings does not clean up completed pods. The job themselves are getting deleted as expected, but the pods are left behind. This seems to be related to What you expected to happen: Expected the pods for now non-existent child jobs of a cronjob to be cleaned up. This is the way it used to work prior to 1.13/ How to reproduce it (as minimally and precisely as possible): run on this manifest: Wait, more than 3 minutes, observe, that while only 3 successful jobs are present, the pods from now deleted jobs are left behind and never get deleted. Anything else we need to know?: pointed out the following relevant places in the code base: deleting a job orphans pods by default and the cronjob controller doesn't do anything different than the default when deleting Environment: Kubernetes version (use ): 1.13.0 Cloud provider or hardware configuration: ubuntu VM in vSphere OS (e.g. from /etc/os-release): 16.04.5 LTS (Xenial Xerus) Kernel (e.g. ): 4.4.0-135-generic Install tools: kubeadm <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig apps
Should include a known issues in 1.13.0 as well /priority critical-urgent
Lemme see if I can easily reproduce this.
/milestone v1.13
Fixes are in (master) and (1.13).
Code change:
} // If any adoptions are attempted, we should first recheck for deletion with // an uncached quorum read sometime after listing Pods (see #42639). <del> canAdoptFunc := controller.RecheckDeletionTimestamp(func() (metav1.Object, error) { </del> <ins> dsNotDeleted := controller.RecheckDeletionTimestamp(func() (metav1.Object, error) { </ins> fresh, err := dsc.kubeClient.ExtensionsV1beta1().DaemonSets(ds.Namespace).Get(ds.Name, metav1.GetOptions{}) if err != nil { return nil, err

Related discussion:
text: <!-- 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 bug What happened: The DaemonSet controller will schedule a pod on a node when the old pod is still in Terminating state. This breaks the expectation that only one pod will be running at a time per node. What you expected to happen: The DaemonSet controller should not let two pods running at the same time on the same node. How to reproduce it (as minimally and precisely as possible): Create a DaemonSet. Set terminationGracePeriodSeconds to be relatively long. Kill a pod. Watch a new pod start on the same node when the old pod is still terminating. Anything else we need to know?: Seems this behavior was introduced in Environment: Kubernetes version (use ): 1.7.2 Cloud provider or hardware configuration**: GKE OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
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 apps
/cc
cc
cc: I think the expected behavior is correct, the terminating pod could be performing an important step such as 'removing a lock' or 'cleanup' etc., we should allow that to gracefully die before creating a new one. IMHO we should revoke to old behavior, but why did we need this new behavior in the first place? That is not clear to me from the PR and Issue.
We don't currently guarantee at least or at most one scheduling for DaemonSet. Both behaviors are under consideration via issue and in the future work section of the . The reason for is to "Make sure that controllers are not adopting children that are marked for deletion" (). This is necessary for GC to work properly.
Well the behavior may be technically undefined, but can I request that in the future changes like this be mentioned in the release notes?
Yes, certainly.
Code change:
} // If any adoptions are attempted, we should first recheck for deletion with // an uncached quorum read sometime after listing Pods (see #42639). <del> canAdoptFunc := controller.RecheckDeletionTimestamp(func() (metav1.Object, error) { </del> <ins> dsNotDeleted := controller.RecheckDeletionTimestamp(func() (metav1.Object, error) { </ins> fresh, err := dsc.kubeClient.ExtensionsV1beta1().DaemonSets(ds.Namespace).Get(ds.Name, metav1.GetOptions{}) if err != nil { return nil, err

Related discussion:
text: Also "The DaemonSet controller should not let two pods running at the same time on the same node." is not necessarily the same thing as respecting termination prior to launching a new Pod. The former implies a more strict requirement than the latter. I think we should consider at least attempting to wait for a terminating Pod to be deleted prior to creating another Pod on the Node for same DaemonSet as default behavior.
will something like work then?
Code change:
// DeleteNominatedPodIfExists does nothing in FIFO. func (f *FIFO) DeleteNominatedPodIfExists(pod *v1.Pod) {} <ins> // NumUnschedulablePods returns the number of unschedulable pods exist in the SchedulingQueue. func (f *FIFO) NumUnschedulablePods() int { return 0 } </ins> // NewFIFO creates a FIFO object. func NewFIFO() *FIFO { return &FIFO{FIFO: cache.NewFIFO(cache.MetaNamespaceKeyFunc)}

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be : Today, the scheduler re-processes unschedulable nodes . Node updates are sent by Kubelet frequently (every 10 seconds) and often times they don't change any of the node properties that could potentially make them feasible. We should be smarter about these updates and move pods to the schedulable queue only when certain properties of nodes change that could make them feasible. These properties include node allocatable, node conditions, taints, labels, .... Why is this needed: Improves performance of the scheduler and avoids doing unnecessary attempts to schedule pods. This is particularly helpful when a cluster has a lot of unschedulable pods. <!-- DO NOT EDIT BELOW THIS LINE --/kind feature This is not a feature really. It is performance optimization, but in the absence of such a label, I need to use "feature" here. /sig scheduling
I can help to fix it. /assign mlmhl
The main reason for this problem is / update their status too frequently and most of these updates are heartbeats without any meaningful change. Recently sig-node introduces a new to alleviate this problem. With this mechanism, kubelet will split heartbeat and node status updates into two independent operations, and reduce the frequency of status updates to once per 1 minute(or more). In the long run this mechanism can indeed alleviate our problems, but at present it does not help us much as this is still an alpha feature and the node status updates frequency is still a bit high(per 1 minute right now).
Maybe we can try comparing old and new nodes after stripping their heartbeat info, like this:
I think that had sent earlier is more efficient. However, that PR does not filter out . In Wei's code, the heartbeat time is removed correctly. I think we should fix this issue and resubmit that PR.
could you resubmit a PR to: disregard in conditions comparison: and (optionally) disregard timestamp in taints comparison:
Thanks for all your advice, a new PR is submitted: This PR does not include your second suggestion(disregard timestamp in taints comparison) as I'm not sure if can be changed when node updating.
Code change:
// DeleteNominatedPodIfExists does nothing in FIFO. func (f *FIFO) DeleteNominatedPodIfExists(pod *v1.Pod) {} <ins> // NumUnschedulablePods returns the number of unschedulable pods exist in the SchedulingQueue. func (f *FIFO) NumUnschedulablePods() int { return 0 } </ins> // NewFIFO creates a FIFO object. func NewFIFO() *FIFO { return &FIFO{FIFO: cache.NewFIFO(cache.MetaNamespaceKeyFunc)}

Related discussion:
text: If it can be changed, I will add this filter later, otherwise I think we can keep the current implementation to make the compare operation simpler and faster. What's more, just as I said in the PR's description, I'm not sure how much side effects this change has on scheduler's resource consumption, as it always copy node's conditions before comparison.
I am thinking whether we could move this logic(whether node became more schedulable) to kubelet, kubelet reports it through heartbeats.
Code change:
ExpectedObject: &unstructured.Unstructured{ Object: map[string]interface{}{ "apiVersion": "example.com/v2", <ins> "metadata":   map[string]interface{}{}, </ins> "other":      "data", "kind":       "foo", },

Related discussion:
text: If a CR converter is wired in and it modifies the input list, the delegating CR converter does not protect against this. A converter cannot effect the input list Not really possible externally - it's a coding issue that the current converters don't hit. No response <details</details<detailsN/A </details<details</details<details</details<details</details<details</details
/sig api-machinery /assign
/triage accepted
Code change:
} } } <ins> // TestProcessHostnameOverrideFlag tests processing hostname-override arg func TestProcessHostnameOverrideFlag(t *testing.T) { testCases := []struct { name                 string hostnameOverrideFlag string expectedHostname     string }{ { name:                 "Hostname from config file", hostnameOverrideFlag: "", expectedHostname:     "foo", }, { name:                 "Hostname from flag", hostnameOverrideFlag: "  bar ", expectedHostname:     "bar", }, } for _, tc := range testCases { t.Run(tc.name, func(t *testing.T) { options := NewOptions() options.config = &kubeproxyconfig.KubeProxyConfiguration{ HostnameOverride: "foo", } options.hostnameOverride = tc.hostnameOverrideFlag err := options.processHostnameOverrideFlag() assert.NoError(t, err, "unexpected error %v", err) if tc.expectedHostname != options.config.HostnameOverride { t.Fatalf("expected hostname: %s, but got: %s", tc.expectedHostname, options.config.HostnameOverride) } }) } } </ins>

Related discussion:
text: Making kube-proxy exit on failure to retrieve the node object might cause regressions in some legitimate use-cases. But I have no idea what those are. ?
I have a hard time imagining what the legit cases might be. I am confused, though - I only see this field being used in one very specific place, that would not have the effect you are claiming.
I can't see the error message from log? If kube-proxy failed to create kube-ipvs0 dummy interface, it will log something like "Failed to create dummy interface: kube-ipvs0, error:...".
This breaks Services of type and with . This is problematic for AWS environments where the kubelet is configured to override the hostname (AWS instances default to the short name and for the cloud provider integrations to work this needs to be overridden to the private fqdn of the host).
Any chance we could get this prioritized as a bug fix for v1.11?
cc
After putting a bit more thought into this, would it be possible to standardize on an environment variable that could be set through the downward api to override the default behavior of treating the hostname as the node name in the proxy? That would simplify the configuration on the kubeadm side (no need to override the command with the downward api, only setting the appropriate env variable), and would also provide a more accurate way to retrieve the actual node name for kube-proxy when deployed as a daemonset without the need to interact with the kubelet directly. I would suggest that we could use for this purpose. I'd also be happy to take a stab at implementing the changes needed for the v1.12 cycle.
Code change:
} } } <ins> // TestProcessHostnameOverrideFlag tests processing hostname-override arg func TestProcessHostnameOverrideFlag(t *testing.T) { testCases := []struct { name                 string hostnameOverrideFlag string expectedHostname     string }{ { name:                 "Hostname from config file", hostnameOverrideFlag: "", expectedHostname:     "foo", }, { name:                 "Hostname from flag", hostnameOverrideFlag: "  bar ", expectedHostname:     "bar", }, } for _, tc := range testCases { t.Run(tc.name, func(t *testing.T) { options := NewOptions() options.config = &kubeproxyconfig.KubeProxyConfiguration{ HostnameOverride: "foo", } options.hostnameOverride = tc.hostnameOverrideFlag err := options.processHostnameOverrideFlag() assert.NoError(t, err, "unexpected error %v", err) if tc.expectedHostname != options.config.HostnameOverride { t.Fatalf("expected hostname: %s, but got: %s", tc.expectedHostname, options.config.HostnameOverride) } }) } } </ins>

Related discussion:
text: Pods not getting scheduled on the new node joined to the cluster using kubespray The node joined to the cluster but new pods schedueld on the nodes are failing with error "get https://10.233.0.1 : dial tcp 10.233.0.1: 443 connection refused" Network plugin - calico kube-proxy running in ipvs mode new worker node, can connect to master server ip address over 6443 new worker node, cannot access cluster ip 10.233.0.1 over port 443 , nodelocaldns and kube-proxy pods are in running state on new node -proxy logs show error "invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP" Unable to write event: 'Post https://127.0.0.1:6443/api/v1/namespaces/default/events dial tcp 127.0.0.1:6443 connection refused" -ln output do not show any services addr show output do not show kube-ipvs0 and calico interfaces Can someone please help. Thanks
Code change:
kubelet.containerManager = &localCM{ ContainerManager: cm.NewStubContainerManager(), allocatable: v1.ResourceList{ <del> v1.ResourceCPU:     *resource.NewMilliQuantity(200, resource.DecimalSI), v1.ResourceMemory:  *resource.NewQuantity(100E6, resource.BinarySI), v1.ResourceStorage: *resource.NewQuantity(200*mb, resource.BinarySI), </del> <ins> v1.ResourceCPU:    *resource.NewMilliQuantity(200, resource.DecimalSI), v1.ResourceMemory: *resource.NewQuantity(100E6, resource.BinarySI), </ins> }, }

Related discussion:
text: Local storage is not expected to be available as a scheduling resource in v1.7. Kubelet is incorrectly exposing a resource named . This is incorrect because the feature is alpha and so it requires opt-in via feature flags and, the resource names are invalid. The expected resource names are listed - and . cc This is v1.7 blocker because we cannot expose a new resource in the API and rename it in a subsequent release.
CC I'll find someone on the storage team to address this.
/assign
GitHub didn't allow me to assign the following users: verult. 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
Code change:
func (c *pods) GetLogs(name string, opts *v1.PodLogOptions) *restclient.Request { return c.client.Get().Namespace(c.ns).Name(name).Resource("pods").SubResource("log").VersionedParams(opts, scheme.ParameterCodec) } <ins> // ProxyGet returns a response of the pod by calling it through the proxy. func (c *pods) ProxyGet(scheme, name, port, path string, params map[string]string) restclient.ResponseWrapper { request := c.client.Get(). Namespace(c.ns). Resource("pods"). SubResource("proxy"). Name(net.JoinSchemeNamePort(scheme, name, port)). Suffix(path) for k, v := range params { request = request.Param(k, v) } return request } </ins>

Related discussion:
text: Currently services/proxy is available in client-go, but pods/proxy resource is not. This requires manual usage via the rest client like This can be seen in Kubernetes e2e tests as well
/kind feature /sig api-machinery
Code change:
<ins> # Replication controller tools ## resize.sh Resizes a replication controller to the specified number of pods. ``` $ resize.sh usage: resize.sh <replication controller name> <size> $ resize.sh redisslave 4 ``` ## stop.sh Resizes a replication controller to 0 pods and waits until the pods are deleted. ``` $ stop.sh usage: stop.sh <replication controller name> $ stop.sh redisslave ``` </ins>

Related discussion:
text: kubectl describe emits 1024 NULL characters prior to actual text. This prevents all text-based processing tools from working on its output. /cc
This has got to be due to:
(IRL discussion: there's no reason to pass 1024 0 bytes to NewBuffer.)
Fixing in PR .
Code change:
return } }() <del> defer errorStream.Reset() </del> if e.stdin != nil { <del> headers.Set(api.StreamType, api.StreamTypeStdin) remoteStdin, err := conn.CreateStream(headers) if err != nil { return err } defer remoteStdin.Reset() </del> // TODO this goroutine will never exit cleanly (the io.Copy never unblocks) // because stdin is not closed until the process exits. If we try to call // stdin.Close(), it returns no error but doesn't unblock the copy. It will

Related discussion:
text: We create the stdin stream and immediately start copying local stdin to the container. We do the same for stdout and stderr (create stream, start copying immediately). In the kubelet, we wait to receive all the streams before we start the exec and copy between the streams and the container. The spdy connection frame handling code has 5 frame workers, each with a queue of up to 50 frames. In the event that we try to push more than 50 frames to a single queue before all streams are ready, the 51st attempt to push a frame blocks until there is space available in the queue. But there won't be any space until the server starts reading from the streams, which won't happen until all the streams have been received, so we're stuck at this point. The fix is to create all the streams first, and only start copying after all the streams have been created and the server is ready to copy between the streams and the container. Originally reported here:
FYI
This seems pretty high priority.
It's an easy fix. has already tested the patch for OpenShift and it works. Are we willing to pull it in before is resolved, as that will take longer to put in place?
Here's the patch, for reference:
5 * 50 = 250 frames before you get stuck? Or did I misunderstand?
Oh, I guess all the frames go to the same worker for some reason?
anyway, I'm fine with taking this and cherry picking it. Order doesn't matter; someone has to rebase either way, right?
frames are assigned to each queue based on stream id, so if you sent 50 frames to the stdin stream, that queue fills up and the loop that processes incoming frames is blocked until something starts reading from the stream. Working on a PR now.
Gotcha, thanks. , Andy Goldstein wrote:
an update: I spent some time trying to create an e2e that would fail more often than not without this fix, but I haven't had any luck so far (I have it stream a copy of the kubectl binary from the local system to the pod). The issue that originally uncovered the problem was from running exec on a Windows system, where it reproduces consistently, but I haven't seen it fail much on Linux. I will keep trying...
Code change:
// isPrivileged will return true a pod has any privileged containers func isPrivileged(pod *api.Pod) bool { for _, c := range pod.Spec.InitContainers { <del> if c.SecurityContext == nil { </del> <ins> if c.SecurityContext == nil || c.SecurityContext.Privileged == nil { </ins> continue } if *c.SecurityContext.Privileged {

Related discussion:
text: <!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): panic apiserver invalid memory address Is this a BUG REPORT or FEATURE REQUEST? (choose one): Bug Report <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: aws OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Linux ip-10-50-193-54 4.4.0-59-generic -Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x8664 x8664 x86_64 GNU/Linux Install tools: Others: What happened: Tried to exec: . Got back: apiserver logs: It only seems to happen on this one pod - other pods are fine. What you expected to happen: should succeed or at least give a sensible error message. How to reproduce it (as minimally and precisely as possible): Anything else do we need to know:
There are no errors on the node with the pod. I also tried kubectl v1.4.8 and same problem.
It looks like your pod that's having the issue has a container with a security context, but privileged appears to be nil. Can you confirm that is the case?
Yep that's it. It seems when securityContext is specified without setting , it isn't set correctly to its default of false. e.g. the pod yaml has: Explicitly adding allows exec to succeed.
Ah, this was caused by the kubelet using versioned APIs - for his awareness. Basically any code that depends on nil pointers being set is vulnerable.