Requirements for v0.6

[alculquicondor]

Accepted

Preview Give feedback

1. A summary of Workloads order in queues #168
   kind/feature kind/ux lifecycle/frozen priority/backlog +4
   
2. Managing raw pods #976
   kind/feature +1
   
3. Do not consider priorities when sorting workloads from different ClusterQueues #1283
   kind/feature +1
   
4. A mechanism to stop a ClusterQueue #1284
   kind/feature +1
   
5. A mechanism to suspend a running Job without requeueing #1091
   kind/feature +1
   
6. MVP Multi-cluster support #693
   kind/feature +1
   
7. Policy to put Workloads in front of the queue after eviction #1282
   kind/feature +1
   
8. Support guaranteed resources in kueue #1224
   kind/feature lifecycle/stale +2
   

[alculquicondor]

cc @tenzen-y @kerthcet for thoughts and additional suggestions.

Some of these things are big, so they might need to be split in smaller increments (like multi cluster and hierarchy), just like we did for Pod support (first single, then groups).

[tenzen-y]

I will create an issue to add integration for the Serving use case by Kserve.

Some of these things are big, so they might need to be split in smaller increments (like multi cluster and hierarchy), just like we did for Pod support (first single, then groups).

SGTM

@alculquicondor #79 is already accepted? I think we should take carefully the feature since the feature will provide more complexity to kueue.

Also, I think we should consider if Cohort can functional as an alternative of #79.

[alculquicondor]

@mwielgus is working on a proposal for #79 that guarantees backwards compatibility. And we will have stages so that we can make some progress in 0.6.

The plan is to actually make Cohort an object :)

[tenzen-y]

The plan is to actually make Cohort an object :)

Oh, it sounds like a nice idea. I can't wait for the KEP :)

[kerthcet]

Some feedbacks from our team, hope to support:

• Support guaranteed resources in kueue #1224 if accepted
• Support for hierarchical ClusterQueues #79 as an enterprise demand
• Managing raw pods  #976
• Dashboard support in Kueue #940, this requires more time, but we can start to design now.

Also, it will be great to to hava:

• Support vcjob in kueue #1204, but this involves contributions to volcano upstream, still WIP.

[alculquicondor]

Awesome, it looks like we are inline @kerthcet. But we will probably need extra hands for #940.

[kerthcet]

Now, kueue acts well in resource sharing, but not that fair, like lacking the capacity of #752 and #754. which is now mitigated by #973.

[mimowo]

@alculquicondor should we graduate ProvisioningACC to Beta?

[alculquicondor]

I cleaned up some of the issues.

I would like to cut a release in the first week of February.

#1282 has a basic form, but @tenzen-y wanted to add a few more knobs, which shouldn't be too controversial, so it can probably make it.

I think #1224 is at risk. Last time I checked, the calculations were not quite right. Also it touches some crucial parts of the code, so there might not be enough time to spot bugs. Maybe we can be more coarse about using the feature gate to guard the behavior? In other words, call the feature gate a few times in top level functions, as opposed to call it in multiple smaller functions. Or we can leave it for 0.7 by April? @kerthcet is shepherding this.

Thoughts?

[tenzen-y]

#1282 has a basic form, but @tenzen-y wanted to add a few more knobs, which shouldn't be too controversial, so it can probably make it.

Yes, I want to include #1608 (Part-of #1282) in v0.6 since I changed the API change in #1608.

The design is completed and waiting for the review now.

Also, I want to include #1601 as much as possible, although I'm not sure that we should put it here due to only facing for developers.

I believe that we can finalize #1601 by the end of January since the remaining task for #1601 is only one.

[tenzen-y]

@alculquicondor @mimowo Did you discuss #1269 (comment) anywhere?

@alculquicondor should we graduate ProvisioningACC to Beta?

[alculquicondor]

Nope. But we are capacity constrained, so my answer is no for now.

[tenzen-y]

Nope. But we are capacity constrained, so my answer is no for now.

SGTM
I don't have strong objections.
If I had to say it, we should not delay the release day due to the graduation of ProvisioningACC.