KEP-7029: LocalQueue Default Maximum Execution Time

[kannon92]

What type of PR is this?

/kind kep

What this PR does / why we need it:

Adds KEP-7029 proposing the ability to configure a default maximum execution time on a LocalQueue. When a job is submitted to a LocalQueue with a default maximum execution time configured, the resulting workload will automatically have its maximumExecutionTimeSeconds field set, unless the job already specifies a value via the kueue.x-k8s.io/max-exec-time-seconds label.

This builds on KEP-3125 (maximum execution time) and addresses community requests in:

• per queue workload time to live? #6684
• Wall time limits for ClusterQueues #6587 (comment)

Which issue(s) this PR fixes:

Fixes #7029

Special notes for your reviewer:

This is the KEP only. Implementation will follow in a separate PR.

Does this PR introduce a user-facing change?

NONE

[netlify]

✅ Deploy Preview for kubernetes-sigs-kueue ready!

Name	Link
🔨 Latest commit	32554a5
🔍 Latest deploy log	https://app.netlify.com/projects/kubernetes-sigs-kueue/deploys/69e2c141cfcebe0008c22ea7
😎 Deploy Preview	https://deploy-preview-10596--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 project configuration.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: kannon92
Once this PR has been reviewed and has the lgtm label, please assign tenzen-y for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[kannon92]

/cc @mwielgus @mimowo @tenzen-y

[k8s-triage-robot]

Unknown CLA label state. Rechecking for CLA labels.

Send feedback to sig-contributor-experience at kubernetes/community.

/check-cla
/easycla

[mwielgus]

We have most of the configuration on the CQ level and very very few on LQ, which acts mainly as a pointer to CQ. Why do we need to have it on LQ? How often do you face use cases where multiple LQ pointing to the same CQ would have significantly different max exec time?

[kannon92]

Good question!

For timelimits I could see value in having it in both LQ/CQ.

Other values, like workload priority class or TAS settings, I'm not sure they should be at the CQ level.

Drawing parallels to slurm, it looks like they have time limits at the partition level (I think thats CQ) but you can also set timelimits for users I think.

WDYT @tenzen-y @mimowo @gabesaba?

[kannon92]

@mukund-wayve

I saw you +1 this PR so curious if you have any thoughts on where this config should live.