-
Notifications
You must be signed in to change notification settings - Fork 1.8k
[WIP] pkg/restmapper: use exponential backoff with DynamicRESTMapper calls #1792
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] pkg/restmapper: use exponential backoff with DynamicRESTMapper calls #1792
Conversation
pkg/restmapper/dynamicrestmapper.go
Outdated
return false | ||
} | ||
err = drm.reload() | ||
if err != nil { | ||
// TODO(estroz): HandleError uses a rudimentary backoff by default. | ||
// Should we remove it completely or substitute the default backoff |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it makes sense to have the simple back off as a fall-back before failing completely
pkg/restmapper/dynamicrestmapper.go
Outdated
"k8s.io/client-go/discovery" | ||
"k8s.io/client-go/rest" | ||
"k8s.io/client-go/restmapper" | ||
) | ||
|
||
// TODO(estroz): do we want to return a wait.ErrWaitTimeout if backoff duration | ||
// reaches a maximum? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say yes. Backoff duration hitting its maximum is, in the end, a wait timeout.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm understanding this correctly, we'll block the caller by sleeping for the backoff duration if we attempt a reload and get a NotKindMatchError
. Is that correct?
I wonder if a better UX would be for us to be able to return a "you've been rate-limited" error immediately and let the caller have the chance to do other things in the meantime? On the other hand, that would then probably mean we'd need to return an error that the caller is able to recover the wait duration from.
I suppose if they need concurrency around this, they could do it themselves with their own goroutine.
Thoughts?
@joelanford that would be better UX, especially if this is being used in a reconcile loop. We could use the token bucket approach: if the limiter |
@estroz I was thinking the same think about the reconcile loop issue. @DirectXMan12 This is definitely related to the conversation going in kubernetes-sigs/controller-runtime#321. Any thoughts on the rate-limiting approach? |
4ddb120
to
c6e1229
Compare
c6e1229
to
6f146c2
Compare
@estroz: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
Instead of making two PR's with these changes (one for the SDK, one to upstream |
Description of the change: add exponential backoff to
DynamicRESTMapper.reloadOnErr()
calls.Motivation for the change: see this discussion from #1329.