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.