Skip to content

feat: allow matching USB devices to be scheduled individually - #232

Open
lucbelliveau wants to merge 1 commit into
squat:mainfrom
lucbelliveau:main
Open

lucbelliveau wants to merge 1 commit into
squat:mainfrom
lucbelliveau:main

Conversation

@lucbelliveau

Copy link
Copy Markdown

Currently, when a USB specification matches multiple physical devices, all matches are combined into a single allocatable meta-device. This means that requesting the resource causes all matching USB devices to be allocated to the same Pod.

This PR adds an opt-in individual setting to USB groups. When enabled, the plugin creates a separate allocatable device for each matching instance of the USB group.

For example:

devices:

  • name: camera
    groups:
    • usb:
      • vendor: "1234"
        product: "5678"
        individual: true

If three physical cameras match this specification, the plugin advertises three allocatable devices, allowing three Pods to independently request one camera each.

For groups containing multiple USB specifications, matches are combined by instance to preserve the existing meta-device semantics. For example, matches A1, A2 and B1, B2 produce two allocatable devices: {A1, B1} and {A2, B2}.

The existing behavior remains the default when individual is omitted or set to false, so existing configurations are unaffected.

Tests cover:

the existing grouped behavior;
individually allocatable matches for a single USB specification; and
grouping individual instances across multiple USB specifications.

@squat

squat commented Sep 11, 2026

Copy link
Copy Markdown
Owner

Interesting! I wonder if the current behavior is in fact intentional or a bug. I'm trying to reason about why it would be desirable to have all matching devices allocated as a group. Do you have insight into this? I need to review old code to check. This would help me reason about whether your change should introduced an option or just change the default behavior.

@lucbelliveau

Copy link
Copy Markdown
Author

Afraid I don't know anyone else who uses this plugin, my biggest concern would be to break existing deployments if they rely on the opposite... but coming from someone who had never seen this plugin, I did not expect it to behave the way it did... adding the option with a default to false seemed the sensible thing to do...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants