Tuomas Katila

> New approach designed to be a replacement for the old one. It shouldn't require any configuration or other changes comparing to the previous one. I'd consider it as an...

@uniemimu and/or @hj-johannes-lee can you review this? Seems to require one more approval.

Nothing from my side. Good to go.

I ran some tests on my personal project: https://github.com/tkatila/intel-device-plugins-for-kubernetes/pull/9 If one adds full version details in the comment (x.y.z) dependabot will also update the comment. I haven't tested the dockerfile...

> I haven't tested the dockerfile update. I should test that before this is merged. Well. It doesn't work. Dependabot scanned a purposefully downgraded Dockerfile and deemed it ok. Looking...

One way to achieve updates for demo SHAs: I wrote a small script that uses frizbee to check for latest versions. That script is then used in a workload that...

> My 2 cents is that we could start with the actions pinning only and let the image sha support to evolve a bit (however, it looks the dependabot solution...

@frenchwr sharedDevNum is the option you would most likely want. Any container requesting the `gpu.intel.com/i915` resource with `sharedDevNum > 1` will get "unlimited" access to the GPU. "unlimited" in a...

> * Am I right that running with resource management disabled (default behavior) would make the most sense for our use case? Yes, that's correct, keep it disabled. To enable...

Hi @SeanOMik, weird. I've seen issues with access rights where the render device cannot be accessed. This can be fixed with a securityContext addition: ``` containers: - name: test securityContext:...