Requirements for v0.6

[alculquicondor]

Accepted

Beta 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.

[mimowo]

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.

I'm wondering what is yet needed before graduation, because the KEP says just "User feedback is positive.".

One benefit of graduating to Beta is that we could delete the manifest from DWS example, which currently is required to enable the feature gate.

I share the sentiment that we should not prolong Kueue release just because of that.

[kerthcet]

For #1224, I think the calculations is right now, you can take a look, especially the tests, I'll catch with this until tomorrow evening, I have some urgent tasks in hand. I broke the words, reviewed and generally LGTM.

I think we can finish this until the end of this week if everything goes well .. What's the planning day for new release?

[kerthcet]

FYI, from Feb. 9th, we'll on holiday for Chinese New Year, we hope to finish this work before that time then little code conflicts to solve. 😢

[tenzen-y]

I'm wondering what is yet needed before graduation, because the #1147 says just "User feedback is positive.".

One benefit of graduating to Beta is that we could delete the manifest from DWS example, which currently is required to enable the feature gate.

I'm not familiar with GKE DWS. So, I leave a decision on @alculquicondor whether we include the graduation of ProbisioningACC.

[tenzen-y]

What's the planning day for new release?

@kerthcet Our deadline is 8th Feb (9th Feb at Asia TZ). If all tasks are done earlier, we can release a new version at that time.

[alculquicondor]

I'm not familiar with GKE DWS. So, I leave a decision on Aldo Culquicondor whether we include the graduation of ProvisioningACC.

Sure, it sounds like we don't need extra tests for now. Although thinking about metrics could be useful. I would be ok leaving it for the next release if @mimowo doesn't have time to think about this.

[mimowo]

I think it is better to leave for the next release in that case.

[tenzen-y]

This is the last piece of v0.6: #1709

[alculquicondor]

Implementation is all done. We can work on documentation in parallel to the release steps.

[tenzen-y]

Implementation is all done. We can work on documentation in parallel to the release steps.

SGTM

[alculquicondor]

/close

[k8s-ci-robot]

@alculquicondor: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.