Allow selection of different GPU model types during notebook creation
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 84
- Forks
- 149
- Avg merge
- 5d 15h
- Merged PRs (30d)
- 29
Description
Checks
- I have searched the existing issues.
- My request is related to one of the components in the
kubeflow/notebooksrepository.
Motivation
At the moment, GPUs can only be configured via the resource limit field. This works if the platform administrators want to expose full NVIDIA or AMD gpus via nvidia.com/gpu or amd.com/gpu or partitions via e.g. nvidia.com/12gb.1gb. If multiple GPU model types are offered, there is no easy way to request them from the user perspective. This is only possible via affinities which are not very user friendly.
Implementation
I would allow the administrators to set the node selector via the notebook configuration, additionally to the resource limit field.
For the users , it could look like this:
For the administrators, it the config could look like this:
flavors:
- limitsKey: nvidia.com/gpu
uiName: "NVIDIA H100 NVL (94GB)"
id: "nvidia-h100-nvl-full"
nodeSelector:
"nvidia.com/gpu.product": "NVIDIA-H100-NVL"
We have a working version offering a flavors section next to existing vendors section which we are happy to contribute.
Are you willing & able to help?
- I am able to submit a PR!
- I can help test the feature!
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing notebook creation and the existing vendors and resource-limit configuration. Compare the working flavors approach described in the issue, including administrator-defined node selectors and the user-facing GPU choice. Done means administrators can configure GPU model options and users can select one that applies the corresponding node selector without breaking current GPU requests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes
- Domain
- infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100