Skip to content

Extend spec to allow for "meta" devices. #71

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

Open
elezar opened this issue Jul 5, 2022 · 6 comments
Open

Extend spec to allow for "meta" devices. #71

elezar opened this issue Jul 5, 2022 · 6 comments

Comments

@elezar
Copy link
Contributor

elezar commented Jul 5, 2022

One of the use cases originally proposed for CDI was use of meta devices such as "all". Since these are generally vendor-specific supporting these in the API is not feasible. The proposal is to add a requires field to the device specification to allow for devices to be grouped. (See the example spec below).

The API would have to be extended to:

  • apply the edits for all devices in the requires list in addition to to the container edits specified
  • ensure that there are no cycles in the requires chain.

Open questions:

  • Should the entry in requires be a fully-qualified name?
  • Should we indicate that the entry in the requires list is a device explicitly?
cdiVersion: 0.5.0
kind: nvidia.com/gpu
devices:
- name: all
  requires:
    - GPU-edfee158-11c1-52b8-0517-92f30e7fac88
    - GPU-f22fb098-d1b3-3806-2655-ba25f02229c1
- name: GPU-edfee158-11c1-52b8-0517-92f30e7fac88
  containerEdits:
    mounts:
    - containerPath: /var/run/nvidia-container-devices/GPU-edfee158-11c1-52b8-0517-92f30e7fac88
      hostPath: /dev/null
      options:
      - ro
- name: GPU-f22fb098-d1b3-3806-2655-ba25f02229c1
  containerEdits:
    mounts:
    - containerPath: /var/run/nvidia-container-devices/GPU-f22fb098-d1b3-3806-2655-ba25f02229c1
      hostPath: /dev/null
      options:
      - ro
containerEdits:
  hooks:
  - args:
    - nvidia-container-runtime-hook
    - prestart
    hookName: prestart
    path: nvidia-container-runtime-hook
@elezar
Copy link
Contributor Author

elezar commented Jul 5, 2022

cc @klueska

@bart0sh
Copy link
Contributor

bart0sh commented Jul 18, 2022

Would supporting regexps, wildcards or predefined keywords in the device names be easier to do, e.g. nvidia.com/device=* or nvidia.com/device=all, or nvidia.com/device=gpu* ?

@bart0sh
Copy link
Contributor

bart0sh commented Jul 18, 2022

cc @klihub @kad

@klihub
Copy link
Contributor

klihub commented Sep 27, 2022

Would supporting regexps, wildcards or predefined keywords in the device names be easier to do, e.g. nvidia.com/device=* or nvidia.com/device=all, or nvidia.com/device=gpu* ?

We had that in the original updated API but it was then removed. I see a few options here but since I'm not familiar with the :

  1. re-add support for regexp-based injection
  2. implement something like the above suggested scheme of 'meta'-devices
  3. let a vendor-specific component dynamically generate spec files with 'meta'-entries

All of these have their pros and cons, including

  1. Fairly easy to implement. Might not be flexible enough (or too error prone) if meta-devices can't be picked by a simple enough pattern.
  2. Should be fairly easy to implement. Feels a bit superficial. For static specs, the entries could be added manually or generated.
  3. Already possible now. Requires an extra component.

@kad @bart0sh It's a bit difficult to guesstimate for the rest of us which of these would be sufficiently good or the best fit for the nvidia cases.

Copy link

This issue is stale because it has been open 90 days with no activity. This issue will be closed in 30 days unless new comments are made or the stale label is removed.

Copy link

This issue was automatically closed due to inactivity.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 29, 2024
@elezar elezar reopened this Feb 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants