Skip to content
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

Multiple RateLimiters in a "single" client. #24157

Open
gmarek opened this issue Apr 12, 2016 · 6 comments
Open

Multiple RateLimiters in a "single" client. #24157

gmarek opened this issue Apr 12, 2016 · 6 comments
Labels
lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery.

Comments

@gmarek
Copy link
Contributor

gmarek commented Apr 12, 2016

Ref. #22421

Currently one "client", or rather ClientSet consists of multiple clients (one for each API group). This makes reasoning about QPS per component much harder - clients in a single ClientSet should share a single RateLimiter.

cc @wojtek-t @krousey @wojtek-t

@krousey
Copy link
Contributor

krousey commented Apr 12, 2016

Note there are currently 3 in the v1.2 client set. One for the core API, one for extensions, and one for discovery.

cc @lavalamp @kubernetes/sig-api-machinery

@gmarek gmarek added the sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. label Apr 12, 2016
@lavalamp
Copy link
Member

@caesarxuchao

@krousey
Copy link
Contributor

krousey commented Apr 12, 2016

This is because restclient has the throttler and is also tied to a single group/version. Multiple restclients = multiple throttles. Arguably there should be only one throttler... server side. 😄

k8s-github-robot pushed a commit that referenced this issue Apr 22, 2016
Automatic merge from submit-queue

All clients under ClientSet share one RateLimiter.

Currently we create a rate limiter for each client in client set. It makes the reasoning about rate limiting behavior much harder. This PR changes this behavior and now all clients in the set share single rate limiter. Ref. #24157

cc @lavalamp @wojtek-t
@fejta-bot
Copy link

Issues go stale after 30d 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

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Dec 15, 2017
@wojtek-t
Copy link
Member

/lifecycle frozen

@k8s-ci-robot k8s-ci-robot added the lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. label Dec 15, 2017
@nikhita
Copy link
Member

nikhita commented Mar 4, 2018

/remove-lifecycle stale

@k8s-ci-robot k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Mar 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery.
Projects
None yet
Development

No branches or pull requests

7 participants