Promote kueue apis to V1

[kannon92]

What would you like to be added:
Promote the core Kueue APIs to V1.
Why is this needed:
We would need to use Kueue in more of our products. Many customers would like a stable API to build on top of.

We would like to start the discussion for what it would take to promote the v1beta1(2) APIs to v1 and stablize the API.
Completion requirements:

This enhancement requires the following artifacts:

• Design doc
• API change
• Docs update

The artifacts should be linked in subsequent comments.

[kannon92]

#3192 (comment)

Some context is above.

[kannon92]

It is not clear to me if #768 must be satisfied before we promote to V1 or not.

[mimowo]

Actually, we use in Kueue both alpha and beta.

I'm wondering if we could migrate to v1 only a subset of API which we consider already stable (like Workload, LQ, CQ and so on), while keeping the other still in alpha or beta (like Topology or MultiKueue, or other new features).

This would give us more flexibility and serial that we promote APIs which aren't battle tested yet. In any case new features to Kueue will start in Alpha.

WDYT @kannon92 @tenzen-y ?

[mimowo]

It is not clear to me if #768 must be satisfied before we promote to V1 or not.

This is wishlist for v1beta2, so yes, this should happen before v1

[kannon92]

This would give us more flexibility and serial that we promote APIs which aren't battle tested yet. In any case new features to Kueue will start in Alpha.

I don't think we need features to start in alpha API fields. Unless we are introducing a new API field entirely. One can always add a new field to v1 or v1beta API.

[kannon92]

This is whitelist for v1beta2, so yes, this should happen before v1

My concern is not there isn't really a hard and fast rule on this one so I worry that it will stay as a wishlist with this API in beta while we add more items to it.

[mimowo]

When I was talking about new features I was thinking that the API objects, like recently introduced Topology or Cohort, should go via Alpha API. For extending existing objects, sure we have no choice than extend them.

As for the wishlist, I'm with you, I would like to promote the APIs, but the list is long and so think it will be safer and with less friction if we move via interim step of v1beta2 than directly to v1.

[tenzen-y]

As I commented in #3192 (comment), I would like to wait any API graduation (even v1beta2) for the graduation of the TAS and HirarchyCohort since both are still alpha stage and potentially plan API change.

[kannon92]

I'm wondering if we could migrate to v1 only a subset of API which we consider already stable (like Workload, LQ, CQ and so on), while keeping the other still in alpha or beta (like Topology or MultiKueue, or other new features).

@tenzen-y is there room to do something like this?

I would really like to see some kind of stabilization of the API for at least the core resources.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[kannon92]

/remove-lifecycle stale