jiebi/CodeConvo huggingface dataset:
Code change:
The node selectors gets parsed by in for each node. That work can be done once in . Better performance.
/sig node /sig scheduling /triage accepted /priority backlog
I can try this one. /assign

Related discussion:
text: "k8s.io/apimachinery/pkg/util/sets" "k8s.io/client-go/kubernetes" resourcev1alpha2listers "k8s.io/client-go/listers/resource/v1alpha2" <del> corev1helpers "k8s.io/component-helpers/scheduling/corev1" </del> "k8s.io/component-helpers/scheduling/corev1/nodeaffinity" "k8s.io/dynamic-resource-allocation/resourceclaim" "k8s.io/klog/v2"
Code change:
The node selectors gets parsed by in for each node. That work can be done once in . Better performance.
/sig node /sig scheduling /triage accepted /priority backlog
I can try this one. /assign

Related discussion:
text: // Empty if the Pod has no claims. claims []*resourcev1alpha2.ResourceClaim <del> // The AvailableOnNodes node filters of the claims converted from the // v1 API to nodeaffinity.NodeSelector by PreFilter for repeated // evaluation in Filter. Nil for claims which don't have it. availableOnNodes []*nodeaffinity.NodeSelector </del> // The indices of all claims that: // - are allocated // - use delayed allocation
Code change:
The node selectors gets parsed by in for each node. That work can be done once in . Better performance.
/sig node /sig scheduling /triage accepted /priority backlog
I can try this one. /assign

Related discussion:
text: podSchedulingDirty bool mutex sync.Mutex <ins> informationsForClaim []informationForClaim } type informationForClaim struct { // The availableOnNode node filter of the claim converted from the // v1 API to nodeaffinity.NodeSelector by PreFilter for repeated // evaluation in Filter. Nil for claim which don't have it. availableOnNode *nodeaffinity.NodeSelector // The status of the claim got from the // schedulingCtx by PreFilter for repeated // evaluation in Filter. Nil for claim which don't have it. status *resourcev1alpha2.ResourceClaimSchedulingStatus </ins> } func (d *stateData) Clone() framework.StateData {
Code change:
The node selectors gets parsed by in for each node. That work can be done once in . Better performance.
/sig node /sig scheduling /triage accepted /priority backlog
I can try this one. /assign

Related discussion:
text: return nil, framework.NewStatus(framework.Skip) } <del> s.availableOnNodes = make([]*nodeaffinity.NodeSelector, len(claims)) </del> <ins> s.informationsForClaim = make([]informationForClaim, len(claims)) </ins> for index, claim := range claims { if claim.Spec.AllocationMode == resourcev1alpha2.AllocationModeImmediate && claim.Status.Allocation == nil {
Code change:
The node selectors gets parsed by in for each node. That work can be done once in . Better performance.
/sig node /sig scheduling /triage accepted /priority backlog
I can try this one. /assign

Related discussion:
text: if err != nil { return nil, statusError(logger, err) } <del> s.availableOnNodes[index] = nodeSelector </del> <ins> s.informationsForClaim[index].availableOnNode = nodeSelector } if claim.Status.Allocation == nil && claim.Spec.AllocationMode == resourcev1alpha2.AllocationModeWaitForFirstConsumer { // The ResourceClass might have a node filter. This is // useful for trimming the initial set of potential // nodes before we ask the driver(s) for information // about the specific pod. class, err := pl.classLister.Get(claim.Spec.ResourceClassName) if err != nil { // If the class does not exist, then allocation cannot proceed. return nil, statusError(logger, fmt.Errorf("look up resource class: %v", err)) } if class.SuitableNodes != nil { selector, err := nodeaffinity.NewNodeSelector(class.SuitableNodes) if err != nil { return nil, statusError(logger, err) } s.informationsForClaim[index].availableOnNode = selector } // Now we need information from drivers. schedulingCtx, err := s.initializePodSchedulingContexts(ctx, pod, pl.podSchedulingContextLister) if err != nil { return nil, statusError(logger, err) } s.informationsForClaim[index].status = statusForClaim(schedulingCtx, pod.Spec.ResourceClaims[index].Name) </ins> } }
Code change:
The node selectors gets parsed by in for each node. That work can be done once in . Better performance.
/sig node /sig scheduling /triage accepted /priority backlog
I can try this one. /assign

Related discussion:
text: logger.V(10).Info("filtering based on resource claims of the pod", "pod", klog.KObj(pod), "node", klog.KObj(node), "resourceclaim", klog.KObj(claim)) switch { case claim.Status.Allocation != nil: <del> if nodeSelector := state.availableOnNodes[index]; nodeSelector != nil { </del> <ins> if nodeSelector := state.informationsForClaim[index].availableOnNode; nodeSelector != nil { </ins> if !nodeSelector.Match(node) { logger.V(5).Info("AvailableOnNodes does not match", "pod", klog.KObj(pod), "node", klog.KObj(node), "resourceclaim", klog.KObj(claim)) unavailableClaims = append(unavailableClaims, index)
Code change:
The node selectors gets parsed by in for each node. That work can be done once in . Better performance.
/sig node /sig scheduling /triage accepted /priority backlog
I can try this one. /assign

Related discussion:
text: // We shouldn't get here. PreFilter already checked this. return statusUnschedulable(logger, "resourceclaim must be reallocated", "pod", klog.KObj(pod), "node", klog.KObj(node), "resourceclaim", klog.KObj(claim)) case claim.Spec.AllocationMode == resourcev1alpha2.AllocationModeWaitForFirstConsumer: <del> // The ResourceClass might have a node filter. This is // useful for trimming the initial set of potential // nodes before we ask the driver(s) for information // about the specific pod. class, err := pl.classLister.Get(claim.Spec.ResourceClassName) if err != nil { // If the class does not exist, then allocation cannot proceed. return statusError(logger, fmt.Errorf("look up resource class: %v", err)) } if class.SuitableNodes != nil { // TODO (#113700): parse class.SuitableNodes once in PreFilter, reuse result. matches, err := corev1helpers.MatchNodeSelectorTerms(node, class.SuitableNodes) if err != nil { return statusError(logger, fmt.Errorf("potential node filter: %v", err)) </del> <ins> if selector := state.informationsForClaim[index].availableOnNode; selector != nil { if matches := selector.Match(node); !matches { return statusUnschedulable(logger, "excluded by resource class node filter", "pod", klog.KObj(pod), "node", klog.KObj(node), "resourceclassName", claim.Spec.ResourceClassName) </ins> } <del> if !matches { return statusUnschedulable(logger, "excluded by resource class node filter", "pod", klog.KObj(pod), "node", klog.KObj(node), "resourceclass", klog.KObj(class)) } } // Now we need information from drivers. schedulingCtx, err := state.initializePodSchedulingContexts(ctx, pod, pl.podSchedulingContextLister) if err != nil { return statusError(logger, err) </del> } <del> status := statusForClaim(schedulingCtx, pod.Spec.ResourceClaims[index].Name) if status != nil { </del> <ins> if status := state.informationsForClaim[index].status; status != nil { </ins> for _, unsuitableNode := range status.UnsuitableNodes { if node.Name == unsuitableNode { return statusUnschedulable(logger, "resourceclaim cannot be allocated for the node (unsuitable)", "pod", klog.KObj(pod), "node", klog.KObj(node), "resourceclaim", klog.KObj(claim), "unsuitablenodes", status.UnsuitableNodes)
Code change:
The node selectors gets parsed by in for each node. That work can be done once in . Better performance.
/sig node /sig scheduling /triage accepted /priority backlog
I can try this one. /assign

Related discussion:
text: pod:    podWithClaimName, claims: []*resourcev1alpha2.ResourceClaim{pendingDelayedClaim}, want: want{ <del> filter: perNodeResult{ workerNode.Name: { status: framework.AsStatus(fmt.Errorf(`look up resource class: resourceclass.resource.k8s.io "%s" not found`, className)), }, </del> <ins> prefilter: result{ status: framework.AsStatus(fmt.Errorf(`look up resource class: resourceclass.resource.k8s.io "%s" not found`, className)), </ins> }, postfilter: result{ <del> status: framework.NewStatus(framework.Unschedulable, `still not schedulable`), </del> <ins> status: framework.NewStatus(framework.Unschedulable, `no new claims to deallocate`), </ins> }, }, },
Code change:
During kubelet start up if the system reserved or kube reserved values failed to parse, the kubelet won't start up. The error logged looks like, However, it doesn't not inform the user which system reserved or kube reserved quantity has failed and what was the corresponding value of that quantity. The error log should also container quantity type and the value that failed to parse, so that user can fix them easily. Try to start kubelet with unparsable values of system reserved, something like, The error logged would look like, As you can see above, it doesn't say was not able to parse with the value No response <details</details<details</details<details</details<details</details<details</details<details</details
/kind feature /sig node
/assign
Thanks for Should I close in favour of yours?
Oh sorry, I didn't see your PR. Either way works for me. You can either incorporate ideas from my PR and I'll drop mine, or drop your PR. I don't feel strongly either way.
/triage accepted /priority backlog /assign
Let's go with yours!
Thanks /close (in favor of )
Closing this issue. <detailsIn response to : Thanks (in favor of ) 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

Related discussion:
text: kubeReserved, err := parseResourceList(s.KubeReserved) if err != nil { <del> return err </del> <ins> return fmt.Errorf("--kube-reserved value failed to parse: %w", err) </ins> } systemReserved, err := parseResourceList(s.SystemReserved) if err != nil { <del> return err </del> <ins> return fmt.Errorf("--system-reserved value failed to parse: %w", err) </ins> } var hardEvictionThresholds []evictionapi.Threshold // If the user requested to ignore eviction thresholds, then do not set valid values for hardEvictionThresholds here.
Code change:
During kubelet start up if the system reserved or kube reserved values failed to parse, the kubelet won't start up. The error logged looks like, However, it doesn't not inform the user which system reserved or kube reserved quantity has failed and what was the corresponding value of that quantity. The error log should also container quantity type and the value that failed to parse, so that user can fix them easily. Try to start kubelet with unparsable values of system reserved, something like, The error logged would look like, As you can see above, it doesn't say was not able to parse with the value No response <details</details<details</details<details</details<details</details<details</details<details</details
/kind feature /sig node
/assign
Thanks for Should I close in favour of yours?
Oh sorry, I didn't see your PR. Either way works for me. You can either incorporate ideas from my PR and I'll drop mine, or drop your PR. I don't feel strongly either way.
/triage accepted /priority backlog /assign
Let's go with yours!
Thanks /close (in favor of )
Closing this issue. <detailsIn response to : Thanks (in favor of ) 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

Related discussion:
text: } experimentalQOSReserved, err := cm.ParseQOSReserved(s.QOSReserved) if err != nil { <del> return err </del> <ins> return fmt.Errorf("--qos-reserved value failed to parse: %w", err) </ins> } var cpuManagerPolicyOptions map[string]string
Code change:
During kubelet start up if the system reserved or kube reserved values failed to parse, the kubelet won't start up. The error logged looks like, However, it doesn't not inform the user which system reserved or kube reserved quantity has failed and what was the corresponding value of that quantity. The error log should also container quantity type and the value that failed to parse, so that user can fix them easily. Try to start kubelet with unparsable values of system reserved, something like, The error logged would look like, As you can see above, it doesn't say was not able to parse with the value No response <details</details<details</details<details</details<details</details<details</details<details</details
/kind feature /sig node
/assign
Thanks for Should I close in favour of yours?
Oh sorry, I didn't see your PR. Either way works for me. You can either incorporate ideas from my PR and I'll drop mine, or drop your PR. I don't feel strongly either way.
/triage accepted /priority backlog /assign
Let's go with yours!
Thanks /close (in favor of )
Closing this issue. <detailsIn response to : Thanks (in favor of ) 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

Related discussion:
text: case v1.ResourceCPU, v1.ResourceMemory, v1.ResourceEphemeralStorage, pidlimit.PIDs: q, err := resource.ParseQuantity(v) if err != nil { <del> return nil, err </del> <ins> return nil, fmt.Errorf("failed to parse quantity %q for %q resource: %w", v, k, err) </ins> } if q.Sign() == -1 { return nil, fmt.Errorf("resource quantity for %q cannot be negative: %v", k, v)
Code change:
During kubelet start up if the system reserved or kube reserved values failed to parse, the kubelet won't start up. The error logged looks like, However, it doesn't not inform the user which system reserved or kube reserved quantity has failed and what was the corresponding value of that quantity. The error log should also container quantity type and the value that failed to parse, so that user can fix them easily. Try to start kubelet with unparsable values of system reserved, something like, The error logged would look like, As you can see above, it doesn't say was not able to parse with the value No response <details</details<details</details<details</details<details</details<details</details<details</details
/kind feature /sig node
/assign
Thanks for Should I close in favour of yours?
Oh sorry, I didn't see your PR. Either way works for me. You can either incorporate ideas from my PR and I'll drop mine, or drop your PR. I don't feel strongly either way.
/triage accepted /priority backlog /assign
Let's go with yours!
Thanks /close (in favor of )
Closing this issue. <detailsIn response to : Thanks (in favor of ) 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

Related discussion:
text: case v1.ResourceMemory: q, err := parsePercentage(v) if err != nil { <del> return nil, err </del> <ins> return nil, fmt.Errorf("failed to parse percentage %q for %q resource: %w", v, k, err) </ins> } reservations[v1.ResourceName(k)] = q default:
Code change:
When submitting a windows pod using resource limits on a node with more than one processor group, the specified count is incorrect due to the usage of which does not take processor groups into account. For example: node with 96 cores cpu limit 94 returns This results in a CPU maximum of since the range is from [1, ]: Our initial goal for this was to limit a process to not use all available CPU and therefore render the node uncontrollable. A CPU maximum of instead of for that specific case. For the calculation, it should use the CPU count for all available processor groups instead of just the current one. Launch a node with a lot of CPUs, for example and schedule the following pod on it: Then SSH into the node and inspect the running container using . The value will be set to . (which just uses ) is able to correctly find out the number of CPUs available to a system. Using for calculation or incorporating that code might solve this issue. <details</details<detailsAzure in-tree </details<details</details<details</details<detailscontainerd://1.6.10 </details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig windows
There is already some code which uses GetActiveProcessorCount:
/assign
/triage accepted

Related discussion:
text: package kuberuntime import ( <del> "runtime" </del> v1 "k8s.io/api/core/v1" <ins> "k8s.io/apimachinery/pkg/api/resource" </ins> runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1" "k8s.io/klog/v2" kubecontainer "k8s.io/kubernetes/pkg/kubelet/container" <ins> "k8s.io/kubernetes/pkg/kubelet/winstats" </ins> "k8s.io/kubernetes/pkg/securitycontext" )
Code change:
When submitting a windows pod using resource limits on a node with more than one processor group, the specified count is incorrect due to the usage of which does not take processor groups into account. For example: node with 96 cores cpu limit 94 returns This results in a CPU maximum of since the range is from [1, ]: Our initial goal for this was to limit a process to not use all available CPU and therefore render the node uncontrollable. A CPU maximum of instead of for that specific case. For the calculation, it should use the CPU count for all available processor groups instead of just the current one. Launch a node with a lot of CPUs, for example and schedule the following pod on it: Then SSH into the node and inspect the running container using . The value will be set to . (which just uses ) is able to correctly find out the number of CPUs available to a system. Using for calculation or incorporating that code might solve this issue. <details</details<detailsAzure in-tree </details<details</details<details</details<detailscontainerd://1.6.10 </details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig windows
There is already some code which uses GetActiveProcessorCount:
/assign
/triage accepted

Related discussion:
text: cpuLimit := container.Resources.Limits.Cpu() if !cpuLimit.IsZero() { <del> // Note that sysinfo.NumCPU() is limited to 64 CPUs on Windows due to Processor Groups, // as only 64 processors are available for execution by a given process. This causes // some oddities on systems with more than 64 processors. // Refer https://msdn.microsoft.com/en-us/library/windows/desktop/dd405503(v=vs.85).aspx. </del> // Since Kubernetes doesn't have any notion of weight in the Pod/Container API, only limits/reserves, then applying CpuMaximum only // will better follow the intent of the user. At one point CpuWeights were set, but this prevented limits from having any effect.
Code change:
When submitting a windows pod using resource limits on a node with more than one processor group, the specified count is incorrect due to the usage of which does not take processor groups into account. For example: node with 96 cores cpu limit 94 returns This results in a CPU maximum of since the range is from [1, ]: Our initial goal for this was to limit a process to not use all available CPU and therefore render the node uncontrollable. A CPU maximum of instead of for that specific case. For the calculation, it should use the CPU count for all available processor groups instead of just the current one. Launch a node with a lot of CPUs, for example and schedule the following pod on it: Then SSH into the node and inspect the running container using . The value will be set to . (which just uses ) is able to correctly find out the number of CPUs available to a system. Using for calculation or incorporating that code might solve this issue. <details</details<detailsAzure in-tree </details<details</details<details</details<detailscontainerd://1.6.10 </details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig windows
There is already some code which uses GetActiveProcessorCount:
/assign
/triage accepted

Related discussion:
text: //   https://github.com/kubernetes/kubernetes/blob/56d1c3b96d0a544130a82caad33dd57629b8a7f8/staging/src/k8s.io/cri-api/pkg/apis/runtime/v1/api.proto#L681-L682 //   https://github.com/opencontainers/runtime-spec/blob/ad53dcdc39f1f7f7472b10aa0a45648fe4865496/config-windows.md#cpu //   If both CpuWeight and CpuMaximum are set - ContainerD catches this invalid case and returns an error instead. <del> cpuMaximum := 10000 * cpuLimit.MilliValue() / int64(runtime.NumCPU()) / 1000 // ensure cpuMaximum is in range [1, 10000]. if cpuMaximum < 1 { cpuMaximum = 1 } else if cpuMaximum > 10000 { cpuMaximum = 10000 } wc.Resources.CpuMaximum = cpuMaximum </del> <ins> wc.Resources.CpuMaximum = calculateCPUMaximum(cpuLimit, int64(winstats.ProcessorCount())) </ins> } // The processor resource controls are mutually exclusive on
Code change:
When submitting a windows pod using resource limits on a node with more than one processor group, the specified count is incorrect due to the usage of which does not take processor groups into account. For example: node with 96 cores cpu limit 94 returns This results in a CPU maximum of since the range is from [1, ]: Our initial goal for this was to limit a process to not use all available CPU and therefore render the node uncontrollable. A CPU maximum of instead of for that specific case. For the calculation, it should use the CPU count for all available processor groups instead of just the current one. Launch a node with a lot of CPUs, for example and schedule the following pod on it: Then SSH into the node and inspect the running container using . The value will be set to . (which just uses ) is able to correctly find out the number of CPUs available to a system. Using for calculation or incorporating that code might solve this issue. <details</details<detailsAzure in-tree </details<details</details<details</details<detailscontainerd://1.6.10 </details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig windows
There is already some code which uses GetActiveProcessorCount:
/assign
/triage accepted

Related discussion:
text: return wc, nil } <ins> // calculateCPUMaximum calculates the maximum CPU given a limit and a number of cpus while ensuring it's in range [1,10000]. func calculateCPUMaximum(cpuLimit *resource.Quantity, cpuCount int64) int64 { cpuMaximum := 10 * cpuLimit.MilliValue() / cpuCount // ensure cpuMaximum is in range [1, 10000]. if cpuMaximum < 1 { cpuMaximum = 1 } else if cpuMaximum > 10000 { cpuMaximum = 10000 } return cpuMaximum } </ins>