mirror of
https://github.com/k3s-io/kubernetes.git
synced 2026-07-19 07:25:19 +00:00
2e966244ed
If a ResourceSlice got published by the ResourceSlice controller in a DRA driver and then that ResourceSlice got deleted quickly (within one minute, the mutation cache TTL) by someone (for example, the kubelet because of a restart), then the controller did not react properly to the deletion unless some other event triggered the syncing of the pool. Found while adding upgrade/downgrade tests with a driver which keeps running across the upgrade/downgrade. The exact sequence leading to this were: - controller adds ResourceSlice, schedules a sync for one minute in the future (the TTL) - someone else deletes the ResourceSlice - add and delete events schedule another sync 30 seconds in the future (the delay), *overwriting* the other scheduled sync - sync runs once, finds deleted slices in the mutation cache, does not re-create them, and also does not run again One possible fix would be to set a resync period. But then work is done periodically, whether it's necessary or not. Another fix is to ensure that the TTL is shorter than the delay. Then when a sync occurs, all locally stored additional slices are expired. But that renders the whole storing of recently created slices in the cache pointless. So the fix used here is to keep track of when another sync has to run because of added slices. At the end of each sync, the next sync gets scheduled if (and only if) needed, until eventually syncing can stop.