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

Expose Flavors in LocalQueue Status #3122

Closed
1 of 3 tasks
Tracked by #3192
KPostOffice opened this issue Sep 23, 2024 · 6 comments · Fixed by #3143
Closed
1 of 3 tasks
Tracked by #3192

Expose Flavors in LocalQueue Status #3122

KPostOffice opened this issue Sep 23, 2024 · 6 comments · Fixed by #3143
Assignees
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:
Add a status field to LocalQueue which lists out available flavors

Why is this needed:
I would like to be able to see the resource flavors available in each LocalQueue that I have access to

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 Sep 23, 2024
@mimowo
Copy link
Contributor

mimowo commented Sep 24, 2024

Updating the flavors in status will eat QPS to update the information which is just one step away so I would prefer to understand what is the use-case.

Would it work for you composing these queries:

CQ_NAME=$(kubectl get lq/user-queue -ojson | jq -r .spec.clusterQueue)
kubectl get cq/$CQ_NAME -ojson | jq .spec.resourceGroups\[\].flavors\[\].name

If this works, maybe just need a docs update for "common tasks", or extend kueuectl?

/cc @mwielgus @alculquicondor

@alculquicondor
Copy link
Contributor

Updating the flavors in status will eat QPS to update the information which is just one step away so I would prefer to understand what is the use-case.

We already have API calls to populate the usage, so this wouldn't add additional calls.

Would it work for you composing these queries

This might not work, depending on the RBAC rules, as users might not have read access to ClusterQueues.

@mimowo
Copy link
Contributor

mimowo commented Sep 24, 2024

I see, sounds good

@tenzen-y
Copy link
Member

Would it work for you composing these queries

This might not work, depending on the RBAC rules, as users might not have read access to ClusterQueues.

The RBAC permission deeply depends on the organization's policies. So, it might be better to add troubleshooting guide or any dedicated task document how to obtain the tied resourceFlavors.

@KPostOffice
Copy link
Contributor Author

This might not work, depending on the RBAC rules, as users might not have read access to ClusterQueues.

This is exactly the issue we are facing. Letting the users know the flavors is useful since it can give an idea of the capabilities provided by a LocalQueue. (i.e. one flavor may have newer GPUs)

@mbobrovskyi
Copy link
Contributor

/assign

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
5 participants