Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for binding CQs to Users and Groups #3922

Open
3 tasks done
KPostOffice opened this issue Jan 2, 2025 · 2 comments
Open
3 tasks done

Add support for binding CQs to Users and Groups #3922

KPostOffice opened this issue Jan 2, 2025 · 2 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@KPostOffice
Copy link
Contributor

What would you like to be added:

A way to bind CQs to users and groups

Why is this needed:

In some cases the batch admin isn't required to be in the loop when new namespaces are created. When a new namespace is created a new LQ has to be created so that users in that namespace can use Kueue quota management. As it stands this requires batch admin since the ability to create LQs more or less allows users to point to any CQ on the K8 cluster. I want the ability to be more permissive with who can create LQs while still limiting it based on spec.clusterQueue

I've created a small PoC with how I envision this working

https://github.com/KPostOffice/kueue/tree/cq-binding

Completion requirements:

This enhancement requires the following artifacts:

  • Design doc
  • API change
  • Docs update

The artifacts should be linked in subsequent comments.

@KPostOffice KPostOffice added the kind/feature Categorizes issue or PR as related to a new feature. label Jan 2, 2025
@kannon92
Copy link
Contributor

kannon92 commented Jan 6, 2025

I've created a small PoC with how I envision this working

Maybe you can open this up as a PR in your branch so you could gather feedback.

@KPostOffice
Copy link
Contributor Author

Maybe you can open this up as a PR in your branch so you could gather feedback.

Good idea. This would require a KEP as well I think.

Here is the link to the PR on my fork

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

No branches or pull requests

2 participants