You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current system, the daemon set sets states in instance allocation to created (when mig slice is created on GPU with configmap added to pod namespaces) and deleted (when mig slice is deleted from the GPU with configmap deleted from the namespace).
The controller can listen to config map events and move allocation to ungated when a config map create event occurs or remove allocation when a config map delete event occurs. This approach reduces the ping-pong for changing allocation status by two controllers for a pod.
The text was updated successfully, but these errors were encountered:
Thanks, @sairameshv. Excellent summary; yes, this is what we want to achieve. We should continue to follow the design of creating before deleting. @harche mentioned out-of-order event triggers like config map deletes events, that could occur before creating, which we need to handle in the controller logic.
In the current system, the daemon set sets states in instance allocation to
created
(when mig slice is created on GPU with configmap added to pod namespaces) anddeleted
(when mig slice is deleted from the GPU with configmap deleted from the namespace).The controller can listen to config map events and move allocation to
ungated
when a config map create event occurs or remove allocation when a config map delete event occurs. This approach reduces the ping-pong for changing allocation status by two controllers for a pod.The text was updated successfully, but these errors were encountered: