cncf-tags
Add Windows Support for Devices
From https://github.com/container-orchestrated-devices/container-device-interface/pull/27:
To support Windows we'd need to add Windows Device properties: ID and IDType, make Path optional and change oci.go code to detect OS type and use either LinuxDevice or WindowsDevice as a target.
This needs to be a followup PR
There's significant overlap between the features of CDI and the Windows-built-in C:\Windows\system32\containers\devices.def and related files. There's a discussion of devices.def at https://github.com/kubernetes/kubernetes/issues/97739#issuecomment-767238485. I'm not sure how and where that file would support vendor-provided details though.
And worth noting from there:
especially because we're planning on moving away from relying on that file in favor of passing in those additional configurations as part of a container create call to HCS.
So CDI seems like it might be the right spec to use to define "those additional configurations", which would also help with the 'vendor-provided' aspect.
It might be a useful thought-experiment to work out what the CDI json would look like to implement the current contents of that file.
There is also some support in Windows for vendor-provided graphics drivers to install other files into Hyper-V-isolated containers when booted, see the discussion of CopyToVmOverwrite on Microsoft Docs and this blog post exploring the behaviour in more detail. I have no personal experience with this part of the system, so I don't know off-hand why it's only applied to Hyper-V-isolated containers (and full Hyper-V VMs, I suspect...) or even if this is still accurate for Windows Server 2022.
I believe this system is graphics driver-specific, though.
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.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
- @elezar I see this one is related to https://github.com/kubernetes/kubernetes/issues/97739 - probably should not be closed because of that? Is there a "frozen" label to prevent it from being closed by the stale-bot?
(I arrived here through https://github.com/moby/moby/blob/2c0100fbde612ecbaae3a08f960ae726aa57ecc7/cmd/dockerd/daemon.go#L272-L278)
We don't have the same bot as other projects at present. Let's reopen it and I'll look into a frozen label.
Thanks! I think it has some options to exempt issues or PRs based on labels; https://github.com/actions/stale?tab=readme-ov-file#exempt-issue-labels
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. To skip these checks, apply the "lifecycle/frozen" label.
Hmm, looks like we implemented the lifecycle/frozen label (at least partially) for this ticket, but never actually added the label here.
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. To skip these checks, apply the "lifecycle/frozen" label.