jiebi/CodeConvo huggingface dataset:
Change:
if addr != nil { node.Status.HostIP = node.Name } else { <del> addrs, err := net.LookupIP(node.Name) </del> <ins> addrs, err := lookupIP(node.Name) </ins> if err != nil { glog.Errorf("Can't get ip address of node %s: %v", node.Name, err) } else if len(addrs) == 0 {

Discussion:
It seems like this depends on the network condition as I first noticed this while on a plane, and it happens to me every so often but never on travis. Offenders are TestSyncNodeStatusDeletePods and TestSyncNodeStatusTransitionTime. This may be reproducible by disconnecting network connection but also happens sometimes while connected. is a call to net.LookupIP(), I'll investigate more.
This also occurs on OSX over a VPN (at least, for my VPN it does). Each call to net.LookupIP(name) takes 30s and fails correctly. As a result, the entire unit test times out. That same function call fails fast on Linux.
cc
For other runtime, we can just mock out net, time. I'd really like to know how to do mocking in go. Using interface seems overkill.
Change:
return nodeIP } <ins> func detectNumCPU() int { // try get numCPU from /sys firstly due to a known issue (https://github.com/kubernetes/kubernetes/issues/99225) _, numCPU, err := machine.GetTopology(sysfs.NewRealSysFs()) if err != nil || numCPU < 1 { return goruntime.NumCPU() } return numCPU } </ins> func getDetectLocalMode(config *proxyconfigapi.KubeProxyConfiguration) (proxyconfigapi.LocalMode, error) { mode := config.DetectLocalMode switch mode {

Discussion:
A new flag indicating how kube-proxy gets the number of CPUs, either from goruntime or . In kube-proxy, we can use to set node's , the resulting is . We have nodes where pods with none CPU policy and static CPU policy are running together. Pods like kube-proxy are running in none CPU policy by default, and they only gets CPUs left by static CPU policy pods. If static CPU policy pods take away most CPUs cores, kube-proxy can only get one or two cores, then will be set to a very small values. In this case, a lot packet failure can occur. When we set kube-proxy to work in static CPU policy, kube-proxy only gets the number of CPUs selected by the CPU policy, not the number of total CPUs on the node. This may surprise users who are only trying to limit kube-proxy's CPU usages, but resulting in some conntrack fulls faults. Please let me know if this enhancement is reasonable, so I can send a pr later. Thanks!
/sig network
Is it refer to deploy order of kube-proxy? If kube-proxy deploy first in node, will it get just one or two core?
By one or two I mean kube-proxy gets a small number of CPU cores, because most of CPU cores are allocated to static policy pods, sorry for the misunderstanding. The number of conntrack-max depends on the CPU cores when kube-proxy started, even kube-proxy was first deployed, it can get restarted or redeployed by some reasons. Then the conntrack-max will change.
yeah, when kube-proxy deploy firstly, Maybe it can see the whole cpu nums from shared cpu(/var/lib/kubelet/cpumanagestate when kubelet start with static cpu policy). But I think it is a bug for kube-proxy. The cpu info can also get from node resource info. So will it be suitable to add a flag to set cpu num?
Maybe, or we can add a flag for user to choose where kube-proxy should get CPU informations from. There maybe some multi-tenant scenarios where kube-proxy are deployed for per tenant so they would like to limit conntrack-max by CPU cores allocated to each tenant.
I think the simple fix is to replace with something that counts /proc/cpuinfo. I don't know of anyone running multiple proxies, and I don't think it would work well. The intention was "all the CPUs on the node". PRs welcome!
/triage accepted
Change:
return allErrs } <del> func validateContainers(containers []core.Container, volumes map[string]core.VolumeSource, fldPath *field.Path) field.ErrorList { </del> <ins> func validateContainers(containers []core.Container, isInitContainers bool, volumes map[string]core.VolumeSource, fldPath *field.Path) field.ErrorList { </ins> allErrs := field.ErrorList{} if len(containers) == 0 {

Discussion:
I found that kubelet will not allocate hostports specified from initContainers. And PodFitsHostPorts in kube-scheduler does not take initContainer into consideration. Also, kube-apiserver think such pod is illegal, but I think it OK. We should make the behavior of spec.HostPorts in initContainer clear
/sig node
Exactly. I think this makes sense. Since initContainers are expected to be completed, we should not expose extra port mappings during creating pod sandbox, which may bring in security risks.
Sounds good to me.
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
/remove-lifecycle stale
Change:
return errors.Errorf("couldn't retrieve StaticPodSpec for %q", componentName) } <ins> // print all volumes that are mounted for _, v := range spec.Spec.Volumes { klog.V(2).Infof("[control-plane] adding volume %q for component %q", v.Name, componentName) } </ins> // if kustomizeDir is defined, customize the static pod manifest if kustomizeDir != "" { kustomizedSpec, err := staticpodutil.KustomizeStaticPod(&spec, kustomizeDir)

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : when using kubeadm init include Why is this needed: the log only show extra-volumes for that control-plane? like this
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig kubeadm 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
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig kubeadm 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
/area kubeadm /kind cleanup /sig cluster-lifecycle
what version of kubeadm are you using?
this minor issue is in master too. the fix is in this PR:
Change:
return pod, podStats } <ins> func makePodWithLocalStorageCapacityIsolationOpen(name string, priority int32, requests v1.ResourceList, limits v1.ResourceList, memoryWorkingSet string) (*v1.Pod, statsapi.PodStats) { vol := newVolume("local-volume", v1.VolumeSource{ EmptyDir: &v1.EmptyDirVolumeSource{ SizeLimit: resource.NewQuantity(requests.Memory().Value(), resource.BinarySI), }, }) var vols []v1.Volume vols = append(vols, vol) pod := newPod(name, priority, []v1.Container{ newContainer(name, requests, limits), }, vols) var podStats statsapi.PodStats switch name { case "empty-dir": podStats = newPodMemoryStats(pod, *resource.NewQuantity(requests.Memory().Value()*2, resource.BinarySI)) case "container-ephemeral-storage-limit": podStats = newPodMemoryStats(pod, *resource.NewQuantity(limits.StorageEphemeral().Value(), resource.BinarySI)) case "pod-ephemeral-storage-limit": podStats = newPodMemoryStats(pod, *resource.NewQuantity(limits.StorageEphemeral().Value()*2, resource.BinarySI)) default: podStats = newPodMemoryStats(pod, resource.MustParse(memoryWorkingSet)) } return pod, podStats } </ins> func makeMemoryStats(nodeAvailableBytes string, podStats map[*v1.Pod]statsapi.PodStats) *statsapi.Summary { val := resource.MustParse(nodeAvailableBytes) availableBytes := uint64(val.Value())

Discussion:
As I was reading the test code, I noticed that we are missing a pretty large chunk of logic around localStorageCapacityIsolation. This feature was GA in 1.25 so it would be ideal to have unit test coverage around this code. This code monitors whether or not there is a violation in temporary storage and if there is it would evict the pod. One should be able to intiailize the manager with of true and then write some test cases to verify this behavior. /help /sig node /good-first-issue /kind bug
/cc do you have any recollection why there weren't tests for this path?
I can help with this. can you assign me after jingxu replies to you?(for more context here)
that would be great !
you're welcome. do you have any context here that why didn't cover localStorageCapacityIsolation?
I don't recall a specific reason. The feature was implemented a while back.
/assign
Hey Are you still working. If not can I take this up?
hi, yes I'm still working on it
hii I am new to k8s , so i wanna know can I use windows os for it? if yes would you show me how to get nodes...
hi, the answer is yes you can use windows and I think if you need support you better open another issue and @ me there, as this issue is not for discuss how to run k8s on windows
/remove-kind bug /kind feature /triage accepted
I see and I am wondering if we have duplicated efforts here. did you end up testing this path in our above PR?
Hey, is someone working on this issue ? or let me know if someone need help
Happy to help with this. Do you still need help
hey, is this currently still unassigned
has a ready for approval. /remove-good-first-issue /remove-help
Change:
klog.Errorf("Failed to get VM object for node: %q. err: +%v", convertToString(nodeName), err) return "", err } <del> isActive, err := vm.IsActive(ctx) </del> <ins> exists, err := vm.Exists(ctx) </ins> if err != nil { <del> klog.Errorf("Failed to check whether node %q is active. err: %+v.", convertToString(nodeName), err) </del> <ins> klog.Errorf("Failed to check whether node %q still exists. err: %+v.", convertToString(nodeName), err) </ins> return "", err } <del> if isActive { </del> <ins> if exists { </ins> return vs.vmUUID, nil } <del> klog.Warningf("The VM: %s is not in %s state", convertToString(nodeName), vclib.ActivePowerState) </del> <ins> klog.Warningf("The VM: %s doesn't exist", convertToString(nodeName)) </ins> return "", cloudprovider.InstanceNotFound }

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: We have k8s cluster with version . And I noticed that if I deleted worker node VM from IAAS, then node stuck in state, I created statefulset before and the pod scheduled on that node was stuck in state, and no new pod was created to replace that. Node should be deleted if no instance is found Related log When I check the log of I could see following log keeps popping up. Looks like node_controller noticed that the VM is gone but it doesn't delete the node. Related code here will return if no instance is found. But it should check if it's VM is deleted not shutdown, then return And it should cherry pick this fix avoiding deleting shutdown node What you expected to happen: After VM is deleted, the node should be deleted, pods assigned to the node should be rescheduled to other available nodes How to reproduce it (as minimally and precisely as possible): k8s cluster. In our case we use PKS. workloads on node worker node VM from IAAS Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: vSphere Cloud Provider
/sig cloud-provider /sig vmware
Same issue as this one The issue and is cluster API repo. We should fix it inside node_controller in k/k
Hi this issue was found when testing windows cluster deployed using PKS. We do have a workaround by manually deleting node using kubectl. Still we wish the fix could go in ASAP. Could you ask someone from upstream to to review the PR that fix this issue? Thank you
, we will try to push this through for v1.20. 1.19 is approaching code thaw, so we can't push this through
Thanks Michael. I'll let my team know.
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
/remove-lifecycle stale
Change:
}, }, }) <del> if err == nil || !strings.Contains(err.Error(), "namespace") { t.Fatalf("expected error that namespace was missing from context") </del> <ins> // Accept "namespace" or "Namespace". if err == nil || !strings.Contains(err.Error(), "amespace") { t.Fatalf("expected error that namespace was missing from context, got: %v", err) </ins> } }

Discussion:
Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: check Anything else we need to know: /cc /milestone v1.17 /priority critical-urgent
/sig cluster-lifecycle These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
/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
Reopening to obvserve the test after the fix was merged.
we updated our jobs after the creation of the new branch. there is now: 1-17-on-1-16 needs more runs, to verify if the fix is valid.
this should be resolved yet still flaky due to sig-apps/StatefulSets and some other conditions.
/close
Closing this issue. <detailsIn response to : /close 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:
t.Errorf("Expected IP address: %s, saw %s", nodeIP, *routeInfo.NextHopIPAddress) } <ins> // test create again without real creation, clean fakeRoute calls fakeRoutes.Calls = []string{} routeInfo.Name = &routeName route.Name = routeName expectedTable.RouteTablePropertiesFormat = &network.RouteTablePropertiesFormat{ Routes: &[]network.Route{routeInfo}, } cloud.rtCache.Set(cloud.RouteTableName, &expectedTable) err = cloud.CreateRoute(context.TODO(), "cluster", "unused", &route) if err != nil { t.Errorf("unexpected error creating route: %v", err) t.FailNow() } if len(fakeRoutes.Calls) != 0 { t.Errorf("unexpected route calls create if not exists, exists: %v", fakeRoutes.Calls) } </ins> // test create route for unmanaged nodes. nodeName := "node1" nodeCIDR := "4.3.2.1/24"

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: Kubernetes shouldn't put route table when it's already been configured. Azure cloud provider should check whether the route has already been created before invoking . What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 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 cloud-provider /priority important-soon
Why this is a bug? A PUT operation should be idempotent and multiple calls should get the same result?
Right. But cloud provider shouldn't make unnecessary API calls.
To check whether it is configured, we need a GET call, so we're going to replace PUT call with GET call in this case?
it's not a replace, we need to LIST routes and check whether it has already been there, then PUT if it's not.
I got your point. But if we directly send a PUT request, seems route RP will also do this comparation? Is there any issue making us have to do the comparation by ourselves instead of sending PUT request to route RP?
It would help to reduce the chances of ARM PUT throttling.
I'd like to work on this
/assign
Change:
options.captureProfile(outputProfile) } <ins> // Cache metric streams for prefilter and filter plugins. for i, pl := range f.preFilterPlugins { f.preFilterPlugins[i] = &instrumentedPreFilterPlugin{ PreFilterPlugin: f.preFilterPlugins[i], metric:          metrics.PluginEvaluationTotal.WithLabelValues(pl.Name(), metrics.PreFilter, f.profileName), } } for i, pl := range f.filterPlugins { f.filterPlugins[i] = &instrumentedFilterPlugin{ FilterPlugin: f.filterPlugins[i], metric:       metrics.PluginEvaluationTotal.WithLabelValues(pl.Name(), metrics.Filter, f.profileName), } } </ins> return f, nil }

Discussion:
We observed degradation in scheduling throughput, putting it under 100 pods/s. Respective pprof of kube-scheduler points it to ! /sig scheduling /kind regression 100 pods/node n/a No response <details</details<details</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
/cc
/sig scalability
Thanks for noticing it /assign
just to confirm this bug is present only in 1.27 ( introduced with pluginevaluationtotal metric) , isn't it ?
Exactly, 1.27+ (so the current master as well) to be specific.
Change:
// This call is idempotent, and must not return an error if the sandbox has // already been removed. rpc RemovePodSandbox(RemovePodSandboxRequest) returns (RemovePodSandboxResponse) {} <del> // PodSandboxStatus returns the status of the PodSandbox. </del> <ins> // PodSandboxStatus returns the status of the PodSandbox. If the PodSandbox is not // present, returns an error. </ins> rpc PodSandboxStatus(PodSandboxStatusRequest) returns (PodSandboxStatusResponse) {} // ListPodSandbox returns a list of PodSandboxes. rpc ListPodSandbox(ListPodSandboxRequest) returns (ListPodSandboxResponse) {}

Discussion:
The behavior when requested id doesn't exist is not defined clearly in CRI. Currently, we define that should return when requested image doesn't exist (), and kubelet is relying on this behavior now (). However, we haven't clearly defined the behavior of and . Currently, they return error when requested sandbox/container doesn't exist, and kubelet is also relying on this behavior. Not super urgent, just track the issue here. /cc
/assign
Added for clarifying the behavior.
Change:
clusters = f.GetRegisteredClusters() ns = f.FederationNamespace.Name // create backend service <del> service = createLBServiceOrFail(f.FederationClientset, ns, FederatedIngressServiceName) </del> <ins> service = createLBServiceOrFail(f.FederationClientset, ns, FederatedIngressServiceName, clusters) </ins> // create the TLS secret secret = createTLSSecretOrFail(f.FederationClientset, ns, FederatedIngressTLSSecretName) // wait for services objects sync

Discussion:
In order to support running tests in parallel, we randomized NodePort selection. There appears to be some evidence that this is not sufficient and is causing e2e test flakes: https://k8s-
Hi, As a need contributor, I'm interesting of solving this issue. I already check the current code, and propose to retry the service creation until success or all possible ports (between FederatedSvcNodePortFirst and FederatedSvcNodePortLast) have been tried. If this approach is fine for you, I can submit a PR soon.
How do you plan to check if the NodePorts are available? In our presubmit test environment, tests run across many instances of federation control planes in parallel, but share the same underlying clusters. So this approach might be viable depending on how and where you plan to check for these used NodePorts.
my approach for getting an available port is a "Dummy" approach: create a list of possible available port, get one of them randomly, then try to create the Service. If Service creation failed. try to use another possible available port, until service creation success or all possible available ports have been tested.
Sounds reasonable to me. Go for it. A couple of caveats: need to create a real list, you could just use the range boundaries. careful about service creation failure. You need to check if the service shard creation failed in the underlying clusters and rollback all those shards before retrying.
thanks for the caveats, I will do soon a PR.
Hi, what is the state of this issue? Is working in this issues with the others issues related to e2e tests?
has a PR to fix this issue -
Change:
visible at runtime in the container. release: v1.9 file: test/e2e/common/node/downwardapi.go <del> - testname: Pod events, verify event from Scheduler and Kubelet codename: '[sig-node] Events should be sent by kubelets and the scheduler about pods scheduling and running  [Conformance]' description: Create a Pod, make sure that the Pod can be queried. Create a event selector for the kind=Pod and the source is the Scheduler. List of the events MUST be at least one. Create a event selector for kind=Pod and the source is the Kubelet. List of the events MUST be at least one. Both Scheduler and Kubelet MUST send events when scheduling and running a Pod. release: v1.9 file: test/e2e/node/events.go </del> - testname: init-container-starts-app-restartalways-pod codename: '[sig-node] InitContainer [NodeConformance] should invoke init containers on a RestartAlways pod [Conformance]'

Discussion:
Related: Noticed this as part of Opened in response to: According to our , the e2e test is ineligible for Conformance. Specifically, the test in question is looking for guaranteed delivery of Events from specific sources (kubelet and default scheduler). This cannot be reasonably expected of all Kubernetes clusters, and thus the test should be demoted from Conformance. For historical context: It looks like this has been part of Conformance sometime since sometime prior to 2015-10-17 (we introduced the [Conformance] tag in 1.2, ref: We overhauled Conformance testing policy (including exclusion of Events) on 2018-10-08 (ref: ) If I wanted to be a language lawyer about this, I could say the policy covers ineligibility for promotion but said nothing about the existing corpus of tests. But I think this was just an honest oversight when we reviewed the existing Conformance tests. Due to the very nature of what this test is verifying, I don't think it's possible to rewrite to avoid Events. Thus, I think it should be demoted from Conformance. SIG Node is free to continue to treat this as release-blocking, but it's not something we can reasonably expect of any Kubernetes cluster /kind cleanup /priority important-soon /milestone v1.23 /sig architecture /area conformance because conformance /sig node because it's a sig-node test
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 Opened to address FYI Since y'all were commenting on
+1