Patrick Ohly
Patrick Ohly
At first glance it sounds significantly more complex than what we have right now. Do we have use cases for `retried` and `avoided` that justify the additional complexity?
> The three well-known statuses have been proposed to allow the writer to control the scheduler’s behavior and decide whether to allocate the same device or not after writing BindingFailureConditions....
> If (https://github.com/kubernetes/kubernetes/issues/135473) is implemented, do you think this issue's feature extension would no longer be necessary? This issue here looks to me like a wish list for a future...
The tolerations could change again later as ResourceClaims and/or DeviceClasses get updated. It can't be a one-time operation, but rather has to be a proper controller.
ResourceClaim and DeviceClass don't even need to be mutable. They could get replaced.
I agree that this is a useful optimization. Hindsight, etc. ...
/assign @deads2k For approval.
> The original issue specifically mentioned: [...] In that issue I only mentioned the most obvious problem with the current code. But what we really want is a reevaluation of...