jiebi/CodeConvo huggingface dataset:
Code change:
Data as of June 3rd, 9:00 PM Eastern. Latest data can be found here: Prow link to the 2 jobs: * Additional Context:
/sig storage cc
I'm working on , it's hard to get a job yaml right at the first time. I'll check iscsi. /assign
/triage accepted /kind failing-test
ci-kubernetes-e2e-storage-kind-disruptive fixed: has 1 green run pull-kubernetes-e2e-storage-kind-disruptive fixed: , it fails when it should fail, it's green otherwise, I'll continue with iscsi.
/reopen it's still red, but at least it installs now:
Reopened this issue. <detailsIn response to : /reopen it's still red, but at least it installs now: 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
e2e-gce-iscsi-serial job passes now: e2e-gce-iscsi is getting greener: I'll let it run for few more days to see if today's failures are flakes. /reopen
Reopened this issue. <detailsIn response to : It's getting greener: /reopen </details
iscsi-serial is green:

Related discussion:
text: configs[ResourceConsumer] = Config{list.PromoterE2eRegistry, "resource-consumer", "1.13"} configs[SdDummyExporter] = Config{list.GcRegistry, "sd-dummy-exporter", "v0.2.0"} configs[VolumeNFSServer] = Config{list.PromoterE2eRegistry, "volume/nfs", "1.3"} <del> configs[VolumeISCSIServer] = Config{list.PromoterE2eRegistry, "volume/iscsi", "2.5"} </del> <ins> configs[VolumeISCSIServer] = Config{list.PromoterE2eRegistry, "volume/iscsi", "2.6"} </ins> configs[VolumeRBDServer] = Config{list.PromoterE2eRegistry, "volume/rbd", "1.0.6"} configs[WindowsServer] = Config{list.MicrosoftRegistry, "windows", "1809"}
Code change:
When a ResourceClaim: uses delayed allocation does not get created for a specific pod (i.e. not from a template) then it currently gets allocated and remains allocated until: scheduling of a pod fails because the node originally chosen for the allocation isn't suitable, in which case the scheduler triggers deallocation via the user deletes the claim What we want instead is that deallocation gets triggered when the last user of such an allocated claim gets removed from . To avoid races, deallocation must be done through . This can be implemented either as a controller or directly in the API server.
/assign
/triage accepted /sig node /priority important-longterm /kind feature

Related discussion:
text: // TODO (#113700): patch claim := claim.DeepCopy() claim.Status.ReservedFor = valid <ins> // When a ResourceClaim uses delayed allocation, then it makes sense to // deallocate the claim as soon as the last consumer stops using // it. This ensures that the claim can be allocated again as needed by // some future consumer instead of trying to schedule that consumer // onto the node that was chosen for the previous consumer. It also // releases the underlying resources for use by other claims. // // This has to be triggered by the transition from "was being used" to // "is not used anymore" because a DRA driver is not required to set // `status.reservedFor` together with `status.allocation`, i.e. a claim // that is "currently unused" should not get deallocated. // // This does not matter for claims that were created for a pod. For // those, the resource claim controller will trigger deletion when the // pod is done. However, it doesn't hurt to also trigger deallocation // for such claims and not checking for them keeps this code simpler. if len(valid) == 0 && claim.Spec.AllocationMode == resourcev1alpha2.AllocationModeWaitForFirstConsumer { claim.Status.DeallocationRequested = true } </ins> _, err := ec.kubeClient.ResourceV1alpha2().ResourceClaims(claim.Namespace).UpdateStatus(ctx, claim, metav1.UpdateOptions{}) if err != nil { return err
Code change:
When a ResourceClaim: uses delayed allocation does not get created for a specific pod (i.e. not from a template) then it currently gets allocated and remains allocated until: scheduling of a pod fails because the node originally chosen for the allocation isn't suitable, in which case the scheduler triggers deallocation via the user deletes the claim What we want instead is that deallocation gets triggered when the last user of such an allocated claim gets removed from . To avoid races, deallocation must be done through . This can be implemented either as a controller or directly in the API server.
/assign
/triage accepted /sig node /priority important-longterm /kind feature

Related discussion:
text: plugin, err := app.StartPlugin(logger, "/cdi", d.Name, nodename, app.FileOperations{ Create: func(name string, content []byte) error { <del> ginkgo.By(fmt.Sprintf("creating CDI file %s on node %s:n%s", name, nodename, string(content))) </del> <ins> klog.Background().Info("creating CDI file", "node", nodename, "filename", name, "content", string(content)) </ins> return d.createFile(&pod, name, content) }, Remove: func(name string) error { <del> ginkgo.By(fmt.Sprintf("deleting CDI file %s on node %s", name, nodename)) </del> <ins> klog.Background().Info("deleting CDI file", "node", nodename, "filename", name) </ins> return d.removeFile(&pod, name) }, },
Code change:
When a ResourceClaim: uses delayed allocation does not get created for a specific pod (i.e. not from a template) then it currently gets allocated and remains allocated until: scheduling of a pod fails because the node originally chosen for the allocation isn't suitable, in which case the scheduler triggers deallocation via the user deletes the claim What we want instead is that deallocation gets triggered when the last user of such an allocated claim gets removed from . To avoid races, deallocation must be done through . This can be implemented either as a controller or directly in the API server.
/assign
/triage accepted /sig node /priority important-longterm /kind feature

Related discussion:
text: ginkgo.Context("with immediate allocation", func() { claimTests(resourcev1alpha2.AllocationModeImmediate) }) <ins> ginkgo.It("must deallocate after use when using delayed allocation", func(ctx context.Context) { parameters := b.parameters() pod := b.podExternal() claim := b.externalClaim(resourcev1alpha2.AllocationModeWaitForFirstConsumer) b.create(ctx, parameters, claim, pod) gomega.Eventually(ctx, func(ctx context.Context) (*resourcev1alpha2.ResourceClaim, error) { return b.f.ClientSet.ResourceV1alpha2().ResourceClaims(b.f.Namespace.Name).Get(ctx, claim.Name, metav1.GetOptions{}) }).WithTimeout(f.Timeouts.PodDelete).ShouldNot(gomega.HaveField("Status.Allocation", (*resourcev1alpha2.AllocationResult)(nil))) b.testPod(ctx, f.ClientSet, pod) ginkgo.By(fmt.Sprintf("deleting pod %s", klog.KObj(pod))) framework.ExpectNoError(b.f.ClientSet.CoreV1().Pods(b.f.Namespace.Name).Delete(ctx, pod.Name, metav1.DeleteOptions{})) ginkgo.By("waiting for claim to get deallocated") gomega.Eventually(ctx, func(ctx context.Context) (*resourcev1alpha2.ResourceClaim, error) { return b.f.ClientSet.ResourceV1alpha2().ResourceClaims(b.f.Namespace.Name).Get(ctx, claim.Name, metav1.GetOptions{}) }).WithTimeout(f.Timeouts.PodDelete).Should(gomega.HaveField("Status.Allocation", (*resourcev1alpha2.AllocationResult)(nil))) }) </ins> }) ginkgo.Context("multiple nodes", func() {
Code change:
We ran into an issue with an old version of k8s 1.18 that we were running where subnet for cluster IP is given as . The control plane comes up just fine but then when you try to create a k8s service, it fails due to a broken behavior with the IP Allocator Since this is not really a supported version of the k8s, I went around digging up a bit more to see what is the regular behavior and found this to be very inconsistent across a few release branches. bash go test -timeout 30m -run ^TestAllocateNextFC$ -v === RUN TestAllocateNextFC ? --- PASS: TestAllocateNextFC (0.00s) PASS ok 0.566s go func TestAllocateNextFC(t *testing.T) { , cidr, err := netutils.ParseCIDRSloppy("fc::/112") if err != nil { t.Fatal(err) } // Need to be replaced with the suitable handler for that version of the branch r, err := newTestAllocator(cidr) if err != nil { t.Fatal(err) } defer r.Destroy() ip, err := r.AllocateNext() if err != nil { t.Fatalf("%s", err.Error()) } fmt.Println(ip.String()) } Add the above Test case under the IP allocator test case No response_ <detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details
/sig network /assign /kind bug
Thanks for helping me with this issue.
/triage accepted /assign

Related discussion:
text: // TODO: move it to k8s.io/utils/net, this is the same as current AddIPOffset() // but using netip.Addr instead of net.IP func addOffsetAddress(address netip.Addr, offset uint64) (netip.Addr, error) { <del> addressBig := big.NewInt(0).SetBytes(address.AsSlice()) r := big.NewInt(0).Add(addressBig, big.NewInt(int64(offset))) addr, ok := netip.AddrFromSlice(r.Bytes()) </del> <ins> addressBytes := address.AsSlice() addressBig := big.NewInt(0).SetBytes(addressBytes) r := big.NewInt(0).Add(addressBig, big.NewInt(int64(offset))).Bytes() // r must be 4 or 16 bytes depending of the ip family // bigInt conversion to bytes will not take this into consideration // and drop the leading zeros, so we have to take this into account. lenDiff := len(addressBytes) - len(r) if lenDiff > 0 { r = append(make([]byte, lenDiff), r...) } else if lenDiff < 0 { return netip.Addr{}, fmt.Errorf("invalid address %v", r) } addr, ok := netip.AddrFromSlice(r) </ins> if !ok { <del> return netip.Addr{}, fmt.Errorf("invalid address %v", r.Bytes()) </del> <ins> return netip.Addr{}, fmt.Errorf("invalid address %v", r) </ins> } return addr, nil }
Code change:
We ran into an issue with an old version of k8s 1.18 that we were running where subnet for cluster IP is given as . The control plane comes up just fine but then when you try to create a k8s service, it fails due to a broken behavior with the IP Allocator Since this is not really a supported version of the k8s, I went around digging up a bit more to see what is the regular behavior and found this to be very inconsistent across a few release branches. bash go test -timeout 30m -run ^TestAllocateNextFC$ -v === RUN TestAllocateNextFC ? --- PASS: TestAllocateNextFC (0.00s) PASS ok 0.566s go func TestAllocateNextFC(t *testing.T) { , cidr, err := netutils.ParseCIDRSloppy("fc::/112") if err != nil { t.Fatal(err) } // Need to be replaced with the suitable handler for that version of the branch r, err := newTestAllocator(cidr) if err != nil { t.Fatal(err) } defer r.Destroy() ip, err := r.AllocateNext() if err != nil { t.Fatalf("%s", err.Error()) } fmt.Println(ip.String()) } Add the above Test case under the IP allocator test case No response_ <detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details
/sig network /assign /kind bug
Thanks for helping me with this issue.
/triage accepted /assign

Related discussion:
text: want:    netip.MustParseAddr("192.168.0.128"), }, { <ins> name:    "IPv4 with leading zeros", address: netip.MustParseAddr("0.0.1.8"), offset:  138, want:    netip.MustParseAddr("0.0.1.146"), }, { name:    "IPv6 with leading zeros", address: netip.MustParseAddr("00fc::1"), offset:  255, want:    netip.MustParseAddr("fc::100"), }, { </ins> name:    "IPv6 offset 255", address: netip.MustParseAddr("2001:db8:1::101"), offset:  255,
Code change:
We ran into an issue with an old version of k8s 1.18 that we were running where subnet for cluster IP is given as . The control plane comes up just fine but then when you try to create a k8s service, it fails due to a broken behavior with the IP Allocator Since this is not really a supported version of the k8s, I went around digging up a bit more to see what is the regular behavior and found this to be very inconsistent across a few release branches. bash go test -timeout 30m -run ^TestAllocateNextFC$ -v === RUN TestAllocateNextFC ? --- PASS: TestAllocateNextFC (0.00s) PASS ok 0.566s go func TestAllocateNextFC(t *testing.T) { , cidr, err := netutils.ParseCIDRSloppy("fc::/112") if err != nil { t.Fatal(err) } // Need to be replaced with the suitable handler for that version of the branch r, err := newTestAllocator(cidr) if err != nil { t.Fatal(err) } defer r.Destroy() ip, err := r.AllocateNext() if err != nil { t.Fatalf("%s", err.Error()) } fmt.Println(ip.String()) } Add the above Test case under the IP allocator test case No response_ <detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details
/sig network /assign /kind bug
Thanks for helping me with this issue.
/triage accepted /assign

Related discussion:
text: subnet: netip.MustParsePrefix("fd00:1:2:3::/64"), want:   netip.MustParseAddr("fd00:1:2:3:FFFF:FFFF:FFFF:FFFF"), }, <ins> { name:   "ipv6 00fc::/112", subnet: netip.MustParsePrefix("00fc::/112"), want:   netip.MustParseAddr("fc::ffff"), }, { name:   "ipv6 fc00::/112", subnet: netip.MustParsePrefix("fc00::/112"), want:   netip.MustParseAddr("fc00::ffff"), }, </ins> } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) {
Code change:
We ran into an issue with an old version of k8s 1.18 that we were running where subnet for cluster IP is given as . The control plane comes up just fine but then when you try to create a k8s service, it fails due to a broken behavior with the IP Allocator Since this is not really a supported version of the k8s, I went around digging up a bit more to see what is the regular behavior and found this to be very inconsistent across a few release branches. bash go test -timeout 30m -run ^TestAllocateNextFC$ -v === RUN TestAllocateNextFC ? --- PASS: TestAllocateNextFC (0.00s) PASS ok 0.566s go func TestAllocateNextFC(t *testing.T) { , cidr, err := netutils.ParseCIDRSloppy("fc::/112") if err != nil { t.Fatal(err) } // Need to be replaced with the suitable handler for that version of the branch r, err := newTestAllocator(cidr) if err != nil { t.Fatal(err) } defer r.Destroy() ip, err := r.AllocateNext() if err != nil { t.Fatalf("%s", err.Error()) } fmt.Println(ip.String()) } Add the above Test case under the IP allocator test case No response_ <detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details
/sig network /assign /kind bug
Thanks for helping me with this issue.
/triage accepted /assign

Related discussion:
text: } } <ins> func TestAllocateNextFC(t *testing.T) { _, cidr, err := netutils.ParseCIDRSloppy("fc::/112") if err != nil { t.Fatal(err) } t.Logf("CIDR %s", cidr) r, err := newTestAllocator(cidr) if err != nil { t.Fatal(err) } defer r.Destroy() ip, err := r.AllocateNext() if err != nil { t.Fatalf("wrong ip %s : %v", ip, err) } t.Log(ip.String()) } </ins> func BenchmarkIPAllocatorAllocateNextIPv4Size1048574(b *testing.B) { _, cidr, err := netutils.ParseCIDRSloppy("10.0.0.0/12") if err != nil {
Code change:
When I put a Pod yaml file without in , started the kubelet and hoped it would create the corresponding staticPod for me, I got the following error, which also caused the staticPod to not be created. I then read the kubelet code and quickly found the problem. When kubelet tries to decode the pod yaml file, it will apply default values and validate the pod. The function to apply the defaults is in . In this function, the is set. This causes an error when is not set, because it causes the '-' character to be at the front. I think kubelet should circumvent this error, because is optional, It is possible for this field not to be set. When Pod's is not set, the '-' character at the start should be avoided, as it will cause an error. Prepare a Pod yaml file without and set it into . If the maintainers think this circumvention change is necessary, I'm happy to contribute code to the kubelet! <details</details<details</details<detailsconsole $ cat /etc/os-release NAME="Alibaba Cloud Linux" VERSION="3 (Soaring Falcon)" ID="alinux" IDLIKE="rhel fedora centos anolis" VERSIONID="3" PLATFORMID="platform:al8" PRETTYNAME="Alibaba Cloud Linux 3 (Soaring Falcon)" ANSICOLOR="0;31" HOMEURL="" $ uname -a Linux cloud 5.10.134-14.al8.x8664 SMP Thu Apr 27 16:46:29 CST 2023 x8664 x8664 x8664 GNU/Linux </details<detailsusing kubeadm </details<details</details<details</details
/sig node
I would like to open a PR to fix this issue, can I be assigned?
If the maintainer thinks this should be fixed, I want it fixed by myself:)
OK
I do not know if a pod without name should be considered valid Please discuss with sig-node before doing anything to understand what is a valid solution for this problem /cc
names are needed for the Pod. I think the correct fix for this issue will be to add validation for static Pods to have a name. This validation is OK to add since Pods without names are not working anyways because of this bug.
Okay, I will submit a PR to add validation for static Pods to have a name.
Hey, I found out that kubelet will apply default value first and then validate the pod. Do you mean to let me add a single validation for static Pods to have a name before applying default value?
hi and If modified according to this logic, it seems that the current code is fine. Current logic: it will use the old pod.Name to generate the new pod.Name , in ValidatePodCreate, it will validate pod name. The pod.Name is already to new pod.Name this case, the original pod does not have a name and will also be recognized. It's just that it's identified with a validation prefixed with "-". The logic of the current validation will recognize the pod without a name. In this way, is it necessary to improve the error information?
/triage accepted
/priority backlog

Related discussion:
text: return false, pod, fmt.Errorf("invalid pod: %#v", obj) } <ins> if newPod.Name == "" { return true, pod, fmt.Errorf("invalid pod: name is needed for the pod") } </ins> // Apply default values and validate the pod. if err = defaultFn(newPod); err != nil { return true, pod, err
Code change:
When I put a Pod yaml file without in , started the kubelet and hoped it would create the corresponding staticPod for me, I got the following error, which also caused the staticPod to not be created. I then read the kubelet code and quickly found the problem. When kubelet tries to decode the pod yaml file, it will apply default values and validate the pod. The function to apply the defaults is in . In this function, the is set. This causes an error when is not set, because it causes the '-' character to be at the front. I think kubelet should circumvent this error, because is optional, It is possible for this field not to be set. When Pod's is not set, the '-' character at the start should be avoided, as it will cause an error. Prepare a Pod yaml file without and set it into . If the maintainers think this circumvention change is necessary, I'm happy to contribute code to the kubelet! <details</details<details</details<detailsconsole $ cat /etc/os-release NAME="Alibaba Cloud Linux" VERSION="3 (Soaring Falcon)" ID="alinux" IDLIKE="rhel fedora centos anolis" VERSIONID="3" PLATFORMID="platform:al8" PRETTYNAME="Alibaba Cloud Linux 3 (Soaring Falcon)" ANSICOLOR="0;31" HOMEURL="" $ uname -a Linux cloud 5.10.134-14.al8.x8664 SMP Thu Apr 27 16:46:29 CST 2023 x8664 x8664 x8664 GNU/Linux </details<detailsusing kubeadm </details<details</details<details</details
/sig node
I would like to open a PR to fix this issue, can I be assigned?
If the maintainer thinks this should be fixed, I want it fixed by myself:)
OK
I do not know if a pod without name should be considered valid Please discuss with sig-node before doing anything to understand what is a valid solution for this problem /cc
names are needed for the Pod. I think the correct fix for this issue will be to add validation for static Pods to have a name. This validation is OK to add since Pods without names are not working anyways because of this bug.
Okay, I will submit a PR to add validation for static Pods to have a name.
Hey, I found out that kubelet will apply default value first and then validate the pod. Do you mean to let me add a single validation for static Pods to have a name before applying default value?
hi and If modified according to this logic, it seems that the current code is fine. Current logic: it will use the old pod.Name to generate the new pod.Name , in ValidatePodCreate, it will validate pod name. The pod.Name is already to new pod.Name this case, the original pod does not have a name and will also be recognized. It's just that it's identified with a validation prefixed with "-". The logic of the current validation will recognize the pod without a name. In this way, is it necessary to improve the error information?
/triage accepted
/priority backlog

Related discussion:
text: // Apply default values and validate pods. for i := range newPods.Items { newPod := &newPods.Items[i] <ins> if newPod.Name == "" { return true, pods, fmt.Errorf("invalid pod: name is needed for the pod") } </ins> if err = defaultFn(newPod); err != nil { return true, pods, err }
Code change:
What happened: Shortly after was merged, the "multiple nodes reallocation works" E2E DRA test started to fail randomly. Please provide links to example occurrences, if any: /sig node /kind bug needs to stay green. No response master n/a No response No response No response No response
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

Related discussion:
text: driver := NewDriver(f, nodes, func() app.Resources { return app.Resources{ NodeLocal:      true, <del> MaxAllocations: 2, </del> <ins> MaxAllocations: 1, </ins> Nodes:          nodes.NodeNames, } }) driver2 := NewDriver(f, nodes, func() app.Resources { return app.Resources{ NodeLocal:      true, <del> MaxAllocations: 2, </del> <ins> MaxAllocations: 1, </ins> Nodes:          nodes.NodeNames, AllocateWrapper: func(