Graduate MultiplePreemptions to Beta

[macsko]

What type of PR is this?

/kind feature

What this PR does / why we need it:

Graduate MultiplePreemptions feature to beta and enable it by default.

Which issue(s) this PR fixes:

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Graduated MultiplePreemptions to Beta and enabled by default.

[macsko]

/cc @alculquicondor @gabesaba

[netlify]

✅ Deploy Preview for kubernetes-sigs-kueue ready!

Name	Link
🔨 Latest commit	61ebacd
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-sigs-kueue/deploys/66c4971ad5aaaf000895f485
😎 Deploy Preview	https://deploy-preview-2864--kubernetes-sigs-kueue.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[alculquicondor]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alculquicondor, macsko

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [alculquicondor]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: af59462725131c035c2202d2b87926370f2a2257

[danielezhu]

Hi, I couldn't find any explicit mention of MultiplePreemptions in the API reference docs or the Concepts/Preemption section and was wondering if someone could please explain what enabling this feature does.

Based on its name, I thought that enabling it allows high-priority workloads to preempt multiple workloads (in other words, by default, workloads can only preempt at most 1 workload), but based on testing a toy example, it seems that high-priority workloads can already do this (even without the MultiplePreemptions feature gate enabled).

Test:

1. Create ClusterQueue with a nominalQuota of 8 cpus
2. Create two low-priority jobs that request 4 cpus each
3. Create a high-priority job that requests 8 cpus

What I observed is that after step 2, both low-priority jobs were running. Upon submitting the high-priority job, both the low-priority jobs became pending and the high-priority job got admitted.

[danielezhu]

Ah, I just realized this has already been merged.

[tenzen-y]

Ah, I just realized this has already been merged.

Yeah, that's true. After we release v0.9.0, this feature is enabled by default, and we can see the details in the website.

[alculquicondor]

We didn't document it because it was meant to become the default behavior and it might not be a very common scenario that users run into. But you can find more details in the original PR #2641

[danielezhu]

Ah, I just realized this has already been merged.

Yeah, that's true. After we release v0.9.0, this feature is enabled by default, and we can see the details in the website.

Just to confirm, this feature is also enabled by default if I'm using v0.8.1, right? Since this PR got merged prior to the 0.8.1 release. Hence why my simple test case allowed both low-prio workloads to get preempted (I'm using 0.8.1).

[alculquicondor]

The feature will only be enabled by default in v0.9. Your test case has always worked.

This feature is about multiple preemptions from multiple ClusterQueues in a cohort. It always faster throughput of preemptions when pods take a long time to finish.

[danielezhu]

The feature will only be enabled by default in v0.9. Your test case has always worked.

This feature is about multiple preemptions from multiple ClusterQueues in a cohort. It always faster throughput of preemptions when pods take a long time to finish.

Thanks for your clarification. The MultiplePreemptions feature is clear to me now; I didn't read the PR description carefully enough at first. Thank you and @tenzen-y very much for your prompt replies and clear explanations!