Hi @MenD32. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: MenD32
Once this PR has been reviewed and has the lgtm label, please assign bigdarkclown for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

@towca I had to revert #8539 in this PR because the partitionable devices feature is only available in k8s.io/api/resource/v1beta1 and has not yet been released into k8s.io/api/resource/v1

@towca this the same PR as #8160 which I had to close because I had some issues reverting #8539.

I'm not sure if reverting was in fact the right move, but in order to add this feature I think there is no way around it...

@towca I had to revert #8539 in this PR because the partitionable devices feature is only available in k8s.io/api/resource/v1beta1 and has not yet been released into k8s.io/api/resource/v1

@nojnhuh can you remind me how this flywheel works?

@towca I had to revert #8539 in this PR because the partitionable devices feature is only available in k8s.io/api/resource/v1beta1 and has not yet been released into k8s.io/api/resource/v1

@nojnhuh can you remind me how this flywheel works?

Doesn't v1 already include everything necessary for partitionable devices? https://github.com/kubernetes/kubernetes/blob/v1.34.1/staging/src/k8s.io/api/resource/v1/types.go#L157-L179

@MenD32 What was the exact issue you were running into that prompted going back to v1beta1?

When I tried to merge with master I had an issue with Device.Basic.ConsumesCounters so I wrongly assumed it wasn't merged into v1 and kept under v1beta1, Now I see that they changed the Device struct to put ConsumesCounters somewhere else... I'll revert the version rollback

@MenD32 thanks a lot for flagging this, haven't bumped into this particular issue before 😅

@jackfrancis @nojnhuh I get that we might be ok for partitionable devices specifically, but will that hold for other features? I.e. can we keep iterating on DRA KEPs in CA while only importing the v1 version of the DRA API? What if there's a KEP that requires some API changes, wouldn't that start in the next beta version? This might be especially painful because only GA APIs get enabled by default, so v1 is the only one we can "rely" on being served for 1.34+.

My understanding is that alpha/beta features that intersect with the existing v1 APIs will be added to v1 and still feature gated, e.g. changes to DeviceClass, ResourceSlice, ResourceClaim(Template).

When a brand new API is introduced, then it will likely land in an alpha/beta API version first, e.g. DeviceTaintRules initially landing in v1alpha3 in 1.33: https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/5055-dra-device-taints-and-tolerations#:~:text=Describe%20the%20mechanism%3A%20resource.k8s.io/v1alpha3%20API%20group

1.35 is the first release cycle where we're adding features since v1 was added, so I'll keep an eye on KEP implementations for this cycle and let you know if that's not actually what happens.

Thanks @nojnhuh, that makes sense, I didn't consider feature-gated fields in v1. And in the brand new API case we could import it and have it behind a separate flag.

/release-note-edit

DRA: partitionable devices support

/label tide/merge-method-squash