Code change:
// from the registered device plugins. func (m *ManagerImpl) Allocate(node *schedulercache.NodeInfo, attrs *lifecycle.PodAdmitAttributes) error { pod := attrs.Pod <ins> devicesToReuse := make(map[string]sets.String) </ins> // TODO: Reuse devices between init containers and regular containers. for _, container := range pod.Spec.InitContainers { <del> if err := m.allocateContainerResources(pod, &container); err != nil { </del> <ins> if err := m.allocateContainerResources(pod, &container, devicesToReuse); err != nil { </ins> return err } <ins> m.podDevices.addContainerAllocatedResources(string(pod.UID), container.Name, devicesToReuse) </ins> } for _, container := range pod.Spec.Containers { <del> if err := m.allocateContainerResources(pod, &container); err != nil { </del> <ins> if err := m.allocateContainerResources(pod, &container, devicesToReuse); err != nil { </ins> return err } <ins> m.podDevices.removeContainerAllocatedResources(string(pod.UID), container.Name, devicesToReuse) </ins> } m.mutex.Lock()

Related discussion:
text: do you think if you have time to implement the solution you mentioned in the above comment We can try to get it into a 1.9 sub release. I think for now, lets just support device reuse among initContainers and normal containers. We can revisit this part when we need to guarantee an Allocate call per container.
Right what I am mentioning here is that it is not possible to do that. The point of the device plugin is so that we can execute vendor specific code before making the device available in the container (e.g: Scrub the GPU memory). I don't think the proposed solution addresses this problem.
Sure. But to clarify, I think if we dont't expect big shock on current implementation, we could only provide limited support on the point, that is, without re-generate runtime information for regular containers, only those whose requested resource is equal to or is a subset of that in init containers could make a resuse(e.g. if we have two init containers, each requests 2 devices, then a regular container that request 3 devices still could not reuse the devices.) Besides, if a initcontainer 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. In sum, since we don't re-generate runtime information, we could only reuse devices per container, not per device, like we do in scheduler. Is that what you mean?
Hmm, that is a good question. I forgot that we now return the combined runtime information in AllocResponse. Then for now, perhaps we should just return an error in device plugin manager Allocate() in case both init containers and containers request the same device plugin resource?
You mean we give up reuse and prohibit users to request same kind of device in init containers and regular containers? that seems a bit weird. And if we decide to do so, we might need to do the check at the first beginning, i.e. in API validation, not wait until it goes into DevicePlugin.
I think for 1.9, we just return an error when both init containers and normal containers of a pod request the same device resource, and document this in the device plugin user guide.