jiebi/CodeConvo huggingface dataset:
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> "testing" "github.com/stretchr/testify/assert"
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: v1 "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <del> utilfeature "k8s.io/apiserver/pkg/util/feature" featuregatetesting "k8s.io/component-base/featuregate/testing" </del> runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1" <del> "k8s.io/kubernetes/pkg/features" </del> <ins> "k8s.io/kubernetes/pkg/kubelet/winstats" </ins> ) func TestApplyPlatformSpecificContainerConfig(t *testing.T) {
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: err = fakeRuntimeSvc.applyPlatformSpecificContainerConfig(containerConfig, &pod.Spec.Containers[0], pod, new(int64), "foo", nil) require.NoError(t, err) <del> expectedCpuMax := ((10000 * 3000) / int64(runtime.NumCPU()) / 1000) </del> <ins> limit := int64(3000) expectedCpuMax := 10 * limit / int64(winstats.ProcessorCount()) </ins> expectedWindowsConfig := &runtimeapi.WindowsContainerConfig{ Resources: &runtimeapi.WindowsContainerResources{ CpuMaximum:         expectedCpuMax,
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: } assert.Equal(t, expectedWindowsConfig, containerConfig.Windows) } <ins> func TestCalculateCPUMaximum(t *testing.T) { tests := []struct { name     string cpuLimit resource.Quantity cpuCount int64 want     int64 }{ { name:     "max range when same amount", cpuLimit: resource.MustParse("1"), cpuCount: 1, want:     10000, }, { name:     "percentage calculation is working as intended", cpuLimit: resource.MustParse("94"), cpuCount: 96, want:     9791, }, { name:     "half range when half amount", cpuLimit: resource.MustParse("1"), cpuCount: 2, want:     5000, }, { name:     "max range when more requested than available", cpuLimit: resource.MustParse("2"), cpuCount: 1, want:     10000, }, { name:     "min range when less than minimum", cpuLimit: resource.MustParse("1m"), cpuCount: 100, want:     1, }, } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { assert.Equal(t, tt.want, calculateCPUMaximum(&tt.cpuLimit, tt.cpuCount)) }) } } </ins>
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 &cadvisorapi.MachineInfo{ <del> NumCores:       processorCount(), </del> <ins> NumCores:       ProcessorCount(), </ins> MemoryCapacity: p.nodeInfo.memoryPhysicalCapacityBytes, MachineID:      hostname, SystemUUID:     systemUUID,
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: // more notes for this issue: // same issue in moby: https://github.com/moby/moby/issues/38935#issuecomment-744638345 // solution in hcsshim: https://github.com/microsoft/hcsshim/blob/master/internal/processorinfo/processor_count.go <del> func processorCount() int { </del> <ins> func ProcessorCount() int { </ins> if amount := getActiveProcessorCount(allProcessorGroups); amount != 0 { return int(amount) }
Code change:
an E2E test that assumes that a service named "kube-dns" exists in the "kube-system" namespace. This is a kubeadm-ism, and the test fails if the cluster DNS is not configured the way kubeadm configures it. Although this E2E test isn't a conformance test, making it functional on non-kubeadm clusters would increase its utility for distributors that may wish to run this E2E test as a conformance test. [sig-network] DNS HostNetwork should resolve DNS of partial qualified names for services on hostNetwork pods with dnsPolicy: ClusterFirstWithHostNet Since we ran it on an OpenShift cluster. No response The test makes assumptions about how the cluster DNS is configured. The test uses (not ), so it does not need to specify , as far as I can tell. Omitting obviates the need to look up the service. I believe that the service lookup was left in as an oversight during the development of the test when it was changed from specifying "None" to specifying "ClusterFirst": Cc: /sig network
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
responded on the pr.
It seems kubeadm inherited the status-quo, I can't find any place that mandates the Service name for DNS Asking for double checking, but the docs seems to mention that this is more a recommendation than a preescription If it seems that the test can be done in a more portable way we should do it

Related discussion:
text: }) ginkgo.It("should work with the pod containing more than 6 DNS search paths and longer than 256 search list characters", func(ctx context.Context) { <del> ginkgo.By("Getting the kube-dns IP") svc, err := f.ClientSet.CoreV1().Services("kube-system").Get(ctx, "kube-dns", metav1.GetOptions{}) framework.ExpectNoError(err, "Failed to get kube-dns service") kubednsIP := svc.Spec.ClusterIP </del> // All the names we need to be able to resolve. namesToResolve := []string{ "kubernetes.default",
Code change:
an E2E test that assumes that a service named "kube-dns" exists in the "kube-system" namespace. This is a kubeadm-ism, and the test fails if the cluster DNS is not configured the way kubeadm configures it. Although this E2E test isn't a conformance test, making it functional on non-kubeadm clusters would increase its utility for distributors that may wish to run this E2E test as a conformance test. [sig-network] DNS HostNetwork should resolve DNS of partial qualified names for services on hostNetwork pods with dnsPolicy: ClusterFirstWithHostNet Since we ran it on an OpenShift cluster. No response The test makes assumptions about how the cluster DNS is configured. The test uses (not ), so it does not need to specify , as far as I can tell. Omitting obviates the need to look up the service. I believe that the service lookup was left in as an oversight during the development of the test when it was changed from specifying "None" to specifying "ClusterFirst": Cc: /sig network
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
responded on the pr.
It seems kubeadm inherited the status-quo, I can't find any place that mandates the Service name for DNS Asking for double checking, but the docs seems to mention that this is more a recommendation than a preescription If it seems that the test can be done in a more portable way we should do it

Related discussion:
text: pod := createDNSPod(f.Namespace.Name, wheezyProbeCmd, jessieProbeCmd, dnsTestPodHostName, dnsTestServiceName) pod.Spec.DNSPolicy = v1.DNSClusterFirst pod.Spec.DNSConfig = &v1.PodDNSConfig{ <del> Nameservers: []string{kubednsIP}, Searches:    testSearchPaths, </del> <ins> Searches: testSearchPaths, </ins> Options: []v1.PodDNSConfigOption{ { Name:  "ndots",
Code change:
handles cases when csiNode is nil. This is condition is used by cluster-autoscaler internal working. However, the log line refers to causing seg fault
/sig scheduling /sig storage
/sig storage /priority important-soon /triage accepted
/sig storage /sig scheduling Note that the lister returns an error for the case when the doesn't exist. But it's ignored here: It looks like the log line that causes the panic was introduced in in 1.25+
cc
/assign
As far as I can tell this issue is only fixed in version 1.27 (by ). Is there a plan to port it back to releases 1.25 and 1.26 as well?
it has already been picked to 1.25 and 1.26 () and will be in the next patch releases for those versions
Great. Thank you for the pointer.

Related discussion:
text: var _ storagelisters.CSINodeLister = CSINodeLister{} // CSINodeLister declares a storagev1.CSINode type for testing. <del> type CSINodeLister storagev1.CSINode </del> <ins> type CSINodeLister []storagev1.CSINode </ins> // Get returns a fake CSINode object. func (n CSINodeLister) Get(name string) (*storagev1.CSINode, error) { <del> csiNode := storagev1.CSINode(n) return &csiNode, nil </del> <ins> for _, cn := range n { if cn.Name == name { return &cn, nil } } return nil, fmt.Errorf("csiNode %q not found", name) </ins> } // List lists all CSINodes in the indexer.
Code change:
handles cases when csiNode is nil. This is condition is used by cluster-autoscaler internal working. However, the log line refers to causing seg fault
/sig scheduling /sig storage
/sig storage /priority important-soon /triage accepted
/sig storage /sig scheduling Note that the lister returns an error for the case when the doesn't exist. But it's ignored here: It looks like the log line that causes the panic was introduced in in 1.25+
cc
/assign
As far as I can tell this issue is only fixed in version 1.27 (by ). Is there a plan to port it back to releases 1.25 and 1.26 as well?
it has already been picked to 1.25 and 1.26 () and will be in the next patch releases for those versions
Great. Thank you for the pointer.

Related discussion:
text: return fmt.Errorf("looking up provisioner name for volume %v: %w", vol, err) } if !isCSIMigrationOn(csiNode, inTreeProvisionerName) { <ins> csiNodeName := "" if csiNode != nil { csiNodeName = csiNode.Name } </ins> klog.V(5).InfoS("CSI Migration is not enabled for provisioner", "provisioner", inTreeProvisionerName, <del> "pod", klog.KObj(pod), "csiNode", csiNode.Name) </del> <ins> "pod", klog.KObj(pod), "csiNode", csiNodeName) </ins> return nil } // Do translation for the in-tree volume.
Code change:
handles cases when csiNode is nil. This is condition is used by cluster-autoscaler internal working. However, the log line refers to causing seg fault
/sig scheduling /sig storage
/sig storage /priority important-soon /triage accepted
/sig storage /sig scheduling Note that the lister returns an error for the case when the doesn't exist. But it's ignored here: It looks like the log line that causes the panic was introduced in in 1.25+
cc
/assign
As far as I can tell this issue is only fixed in version 1.27 (by ). Is there a plan to port it back to releases 1.25 and 1.26 as well?
it has already been picked to 1.25 and 1.26 () and will be in the next patch releases for those versions
Great. Thank you for the pointer.

Related discussion:
text: wantStatus:       framework.NewStatus(framework.Unschedulable, ErrReasonMaxVolumeCountExceeded), }, { <ins> newPod:           inTreeInlineVolPod, existingPods:     []*v1.Pod{inTreeTwoVolPod}, filterName:       "csi", maxVols:          2, driverNames:      []string{csilibplugins.AWSEBSInTreePluginName, ebsCSIDriverName}, migrationEnabled: true, limitSource:      "node", test:             "nil csi node", }, { </ins> newPod:           pendingVolumePod, existingPods:     []*v1.Pod{inTreeTwoVolPod}, filterName:       "csi",
Code change:
handles cases when csiNode is nil. This is condition is used by cluster-autoscaler internal working. However, the log line refers to causing seg fault
/sig scheduling /sig storage
/sig storage /priority important-soon /triage accepted
/sig storage /sig scheduling Note that the lister returns an error for the case when the doesn't exist. But it's ignored here: It looks like the log line that causes the panic was introduced in in 1.25+
cc
/assign
As far as I can tell this issue is only fixed in version 1.27 (by ). Is there a plan to port it back to releases 1.25 and 1.26 as well?
it has already been picked to 1.25 and 1.26 () and will be in the next patch releases for those versions
Great. Thank you for the pointer.

Related discussion:
text: } pvLister = append(pvLister, pv) } } return pvLister }
Code change:
handles cases when csiNode is nil. This is condition is used by cluster-autoscaler internal working. However, the log line refers to causing seg fault
/sig scheduling /sig storage
/sig storage /priority important-soon /triage accepted
/sig storage /sig scheduling Note that the lister returns an error for the case when the doesn't exist. But it's ignored here: It looks like the log line that causes the panic was introduced in in 1.25+
cc
/assign
As far as I can tell this issue is only fixed in version 1.27 (by ). Is there a plan to port it back to releases 1.25 and 1.26 as well?
it has already been picked to 1.25 and 1.26 () and will be in the next patch releases for those versions
Great. Thank you for the pointer.

Related discussion:
text: } func getFakeCSINodeLister(csiNode *storagev1.CSINode) fakeframework.CSINodeLister { <ins> csiNodeLister := fakeframework.CSINodeLister{} </ins> if csiNode != nil { <del> return fakeframework.CSINodeLister(*csiNode) </del> <ins> csiNodeLister = append(csiNodeLister, *csiNode.DeepCopy()) </ins> } <del> return fakeframework.CSINodeLister{} </del> <ins> return csiNodeLister </ins> } func getNodeWithPodAndVolumeLimits(limitSource string, pods []*v1.Pod, limit int64, driverNames ...string) (*framework.NodeInfo, *storagev1.CSINode) {
Code change:
handles cases when csiNode is nil. This is condition is used by cluster-autoscaler internal working. However, the log line refers to causing seg fault
/sig scheduling /sig storage
/sig storage /priority important-soon /triage accepted
/sig storage /sig scheduling Note that the lister returns an error for the case when the doesn't exist. But it's ignored here: It looks like the log line that causes the panic was introduced in in 1.25+
cc
/assign
As far as I can tell this issue is only fixed in version 1.27 (by ). Is there a plan to port it back to releases 1.25 and 1.26 as well?
it has already been picked to 1.25 and 1.26 () and will be in the next patch releases for those versions
Great. Thank you for the pointer.

Related discussion:
text: initCSINode := func() { csiNode = &storagev1.CSINode{ <del> ObjectMeta: metav1.ObjectMeta{Name: "csi-node-for-max-pd-test-1"}, </del> <ins> ObjectMeta: metav1.ObjectMeta{Name: "node-for-max-pd-test-1"}, </ins> Spec: storagev1.CSINodeSpec{ Drivers: []storagev1.CSINodeDriver{}, },