Skip to content

docs(queues): explain that an omitted limit is 0 and fix the example queues - #2532

Merged
gshaibi merged 1 commit into
kai-scheduler:mainfrom
fjvbn2003:docs/queue-limit-default
Nov 9, 2026
Merged

gshaibi merged 1 commit into
kai-scheduler:mainfrom
fjvbn2003:docs/queue-limit-default

Conversation

@fjvbn2003

Copy link
Copy Markdown
Contributor

Description

An omitted limit in a Queue is read as 0, and a 0 limit blocks that resource completely, including the queue's quota. The "Special Values" table describes it as "No additional resources allowed", and the last example is titled "Unlimited Queue - default value is -1", so readers expect a different behavior. The three example queues in this page omit memory (and the hierarchical one also omits limit on cpu and gpu), so when applied as written they leave every pod that requests memory or CPU pending with an OverLimit … Limit is 0 condition.

This PR:

  • rewrites the limit: 0 or unset row and adds a short paragraph saying that each resource is checked on its own and that -1 has to be set explicitly;
  • adds memory: {quota: -1, limit: -1} to the three examples and limit: -1 to the hierarchical example's cpu and gpu;
  • drops "default value is -1" from the "Unlimited Queue" heading.

Tested on KAI Scheduler v0.18.6 (k3s v1.36.5, GPUs simulated with fake-gpu-operator 0.2.1). Same pod for every row: requests: {cpu: 100m, memory: 32Mi}, limits: {nvidia.com/gpu: 1}.

Example Before (as on main) After (this PR)
Basic Queue Pending, Limit is 0 GB (memory) Running
Hierarchical Queue Pending, Limit is 0 cores (CPU) Running
Unlimited Queue Pending, Limit is 0 GB (memory) Running

Documentation only; no code or chart changes. Could a maintainer please add the skip-changelog label?

Related Issues

Fixes #2531

Checklist

  • Self-reviewed (the diff was checked against the before/after run above; see the AI note below)
  • Added/updated tests (if needed): not needed, docs only
  • Updated documentation (if needed)
  • Added a changelog fragment via make changelog (or applied the skip-changelog label): docs only, label requested above

Breaking Changes

None.

Additional Notes

This touches the same file as #2275 (MIG quota accounting), but different lines; the patch was checked to apply cleanly on current main. I will rebase if #2275 merges first.

AI disclosure: this change was prepared with the help of an AI coding assistant (Claude Code). Claude found the mismatch, ran the before/after comparison above in a test VM in my home lab, and drafted the diff and this description.

🤖 Generated with Claude Code

@blacksoxx blacksoxx left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this. The code agrees with the new wording: proportion.go takes queue.Resources.<resource>.Limit as is (memory goes through math.Max(-1, limit*mebibytes)), the Queue CRD has no default for limit, so an omitted limit is 0, and isOverLimit only skips the check when MaxAllowed is exactly -1. A queue that omits memory therefore cannot run any pod that requests memory, which matches the OverLimit condition you saw.

What I checked on c871f61: the three examples now set limit: -1 on every resource that was meant to be unbounded, and the branch merges cleanly into main. Docs-only, so no fragment is needed; a maintainer would have to add the skip-changelog label.

One question rather than a request: the new memory blocks use quota: -1, which also makes the memory quota unlimited, while the GPU examples use quota: 0 for "no guarantee". If the intent is only to lift the cap, quota: 0 with limit: -1 might be the closer example. Leaving that and the decision with the maintainers.

keinanDaniel
keinanDaniel previously approved these changes Oct 28, 2026
@fjvbn2003

fjvbn2003 commented Oct 28, 2026 •

Copy link
Copy Markdown
Contributor Author

Thanks for checking the code path. Agreed, the intent is only to lift the cap, so I switched the memory blocks in the two capped examples to quota: 0 with limit: -1 to match the GPU entries (squashed into 2c23833). The Unlimited Queue example keeps quota: -1, since every resource there is unlimited.

…queues

An omitted limit in a Queue is read as 0, and a 0 limit blocks that
resource completely, including the queue's quota. The Special Values
table described it as "No additional resources allowed" and the last
example was titled "default value is -1", so the three example queues,
which omit memory (and, in the hierarchical one, the cpu and gpu
limits), left every pod that requests memory or CPU pending with an
OverLimit condition.

Describe the actual behavior, set limit: -1 explicitly in the examples
(the memory entries added to the capped examples keep quota: 0, like
the GPU ones), and drop the "default value is -1" heading.

Fixes kai-scheduler#2531

Signed-off-by: YoungjuKim <[email protected]>
Assisted-by: Claude <[email protected]>
@fjvbn2003
fjvbn2003 force-pushed the docs/queue-limit-default branch from 47bd30b to 2c23833 Compare October 28, 2026 15:54
@blacksoxx

Copy link
Copy Markdown
Contributor

Thanks @fjvbn2003, 2c23833 reads right: the two capped examples now use quota: 0 with limit: -1 for memory, matching the GPU entries, and the Unlimited Queue keeps quota: -1.

@fjvbn2003

Copy link
Copy Markdown
Contributor Author

@keinanDaniel the squash push dismissed your earlier approval; the only change since then is the memory quota/limit fix that @blacksoxx confirmed above (2c23833). Could you take another look when you have a moment? Thank you!

@gshaibi
gshaibi added this pull request to the merge queue Nov 9, 2026
Merged via the queue into kai-scheduler:main with commit e5f0f29 Nov 9, 2026
15 of 17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Queue examples in docs/queues/README.md cannot schedule anything: an omitted limit is 0, not -1

4 participants