1b47e6433b
This releases the underlying resource sooner and ensures that another consumer can get scheduled without being influenced by a decision that was made for the previous consumer. An alternative would have been to have the apiserver trigger the deallocation whenever it sees the `status.reservedFor` getting reduced to zero. But that then also triggers deallocation when kube-scheduler removes the last reservation after a failed scheduling cycle. In that case we want to keep the claim allocated and let the kube-scheduler decide on a case-by-case basis which claim should get deallocated. |
||
|---|---|---|
| .. | ||
| metrics | ||
| controller_test.go | ||
| controller.go | ||
| doc.go | ||
| OWNERS | ||
| uid_cache.go | ||