Code change:
return devs.deviceIds } <ins> // Populates allocatedResources with the device resources allocated to the specified <podUID, contName>. func (pdev podDevices) addContainerAllocatedResources(podUID, contName string, allocatedResources map[string]sets.String) { containers, exists := pdev[podUID] if !exists { return } resources, exists := containers[contName] if !exists { return } for resource, devices := range resources { allocatedResources[resource] = allocatedResources[resource].Union(devices.deviceIds) } } // Removes the device resources allocated to the specified <podUID, contName> from allocatedResources. func (pdev podDevices) removeContainerAllocatedResources(podUID, contName string, allocatedResources map[string]sets.String) { containers, exists := pdev[podUID] if !exists { return } resources, exists := containers[contName] if !exists { return } for resource, devices := range resources { allocatedResources[resource] = allocatedResources[resource].Difference(devices.deviceIds) } } </ins> // Returns all of devices allocated to the pods being tracked, keyed by resourceName. func (pdev podDevices) devices() map[string]sets.String { ret := make(map[string]sets.String)

Related discussion:
text: I noticed that you have already add the limitation into the , so I think it's already the decision that we add the limitation as a short-time solution in v1.9 So I posted a PR to add the check in code,, PTAL :)
Use Case: Let say there is a which node has two Devices of a resource type X and the device IDs are X1 and X2. User pod has one init container, lets call it cont-init and one regular container, lets call it cont-reg. Both cont-init and cont-reg requests 2 unit of resource X. cont-init will run some vendor specific code on allocated Devices and then cont-reg will use these 'initiated' devices. I think this is the use case that mentioned. And i feel 2) can handle this. 2) approach will allocate both the devices, X1 and X2, to both the containers. When the containers start, init container, cont-init, will be run first and will run to completion and here devices will get initialized. Strictly after this cont-reg will be started and now this regular container has initialized devices. Where i am wrong?
I guess in RenaudWasTaken 's case, the initialization task is considered to be managed in the plugin, not in init-container, and in init-container we only use the device, so then we might need to call plugin to do recycle action before the device reused by reguler containers. In practical use, both of the two scenarios may exist, it depends on the request of user. Besides, if we don't issue an Allocate gRPC call, we could not ensure a ”complete reuse“: say an init-container requests 2 devices, and we have two regular containers, each requests 1 device, then due to the lack of runtime info re-generation, the devices could only be reused by one of the containers, not both of them.
It is the init containers' job to initialize things and if in some special case device plugin is doing the initialization part, in that case, init containers will not be needed and serve no purpose in pod spec. Specific to example of memory scrubbing, i think this also makes more sense to be done in init container. Once Device's memory is scrubbed, it can be used by regular container. Let try to run your use case with approach 2).