What is the problem you're trying to solve
In multi-tenant clusters, teams need to manage their own job
queues without asking a cluster admin every time. Today, Queue
is cluster-scoped , only admins can create or update it. This
blocks individual teams from using Volcano's scheduling
capabilities (resource sharing, guarantees, hierarchy)
independently within their own namespace.
Describe the solution you'd like
A namespace-scoped NamespaceQueue CRD that:
- Is derived from a parent cluster-scoped Queue
- Supports the same fields: capability, guarantee, deserved,
and hierarchy semantics
- Allows PodGroup/Job to reference a NamespaceQueue exactly
like a cluster Queue — same scheduling behavior
- Keeps existing cluster Queue behavior completely unchanged
for users who don't opt in
I'm applying for the LFX Term 2 mentorship to implement this
exact feature. Before writing any code I wanted to open this
as a formal feature request and get maintainer input on the
design approach.
I've already opened a design discussion here: #5300 with
specific questions on resource accounting and PodGroup
referencing strategy. I've also been reading through
pkg/scheduler/cache/ and pkg/scheduler/plugins/capacity/
to understand the existing Queue model.
Additional context
I've already contributed a Queue docs improvement to
volcano-sh/website: volcano-sh/website#500 (review)
It helped me understand how a pluggable registry pattern
works , the same pattern I plan to use for NamespaceQueue's
controller watching and reconciliation logic.
Documentation Updates
What is the problem you're trying to solve
In multi-tenant clusters, teams need to manage their own job
queues without asking a cluster admin every time. Today, Queue
is cluster-scoped , only admins can create or update it. This
blocks individual teams from using Volcano's scheduling
capabilities (resource sharing, guarantees, hierarchy)
independently within their own namespace.
Describe the solution you'd like
A namespace-scoped NamespaceQueue CRD that:
and hierarchy semantics
like a cluster Queue — same scheduling behavior
for users who don't opt in
I'm applying for the LFX Term 2 mentorship to implement this
exact feature. Before writing any code I wanted to open this
as a formal feature request and get maintainer input on the
design approach.
I've already opened a design discussion here: #5300 with
specific questions on resource accounting and PodGroup
referencing strategy. I've also been reading through
pkg/scheduler/cache/ and pkg/scheduler/plugins/capacity/
to understand the existing Queue model.
Additional context
I've already contributed a Queue docs improvement to
volcano-sh/website: volcano-sh/website#500 (review)
It helped me understand how a pluggable registry pattern
works , the same pattern I plan to use for NamespaceQueue's
controller watching and reconciliation logic.
Documentation Updates