Improve quota replenishment

[deads2k]

Quota replenishment can be slow and irksome in the case of rejected requests. One common example: create with a conflicting name. Quota charges you, but doesn't "uncharge" until it refreshes again.

If we don't need quota to be perfectly, this would be heuristically resolved by registering a time-based recheck on create against a cache of the resource to see if it exists in the store/index based on the reflector. If you check for that particular resource existing in 500 millliseconds, you'll usually make the correct choice since you're basically talking about etcd latency at that point. It possible that you'll be wrong, but a user can't force the system in their favor to gain advantage and the reconciliation of the controller will eventually get it right anyway.

In openshift, this would usually be zero cost, since we run core controllers in-process. In kube, this is non-zero cost (you'd have another cache). I'd like to see the quota admission plugin updated to at least have this as an option or some other solution that can uncharge on failed creates. I see this or a RESTHandler post-hook that can never fail (someone will abuse this) as the best options.

@derekwaynecarr @kubernetes/rh-cluster-infra

[derekwaynecarr]

I am aware of the conflicting name problem we hit with deployments, we also just have this problem generally when you attempt to create invalid objects that fail validation. Per our chat, I am in favor of a RESTHandler post-hook to support refunding quota in this case of a POST that failed validation.

The post-hook cannot depend on look-up of a resource by name since name generation happens after the fact, so in general, the hook would need to probably just know did the request fail or not, and know what to refund based on shared state, so we may want to expose Context on admission attributes. I will hack something up.

Also related: #20113

[0xmichalis]

/sig node
/sig api-machinery

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[nikhita]

/remove-lifecycle rotten
/lifecycle frozen

[utkarsh2102]

Hey,

This hasn't been looked up in ~5 years and has a related PR, which has been closed, too. So I'd be inclined to closing this one. Should you feel differently, please let us know?

/kind feature
/close

[k8s-ci-robot]

@utkarsh2102: You can't close an active issue/PR unless you authored it or you are a collaborator.

In response to this:

Hey,

This hasn't been looked up in ~5 years and has a related PR, which has been closed, too. So I'd be inclined to closing this one. Should you feel differently, please let us know?

/kind feature
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[ehashman]

/remove-lifecycle frozen
/close

[k8s-ci-robot]

@ehashman: Closing this issue.

In response to this:

/remove-lifecycle frozen
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.