-
Notifications
You must be signed in to change notification settings - Fork 33
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
Notebooks 2.0 // Backend // add a rate limiting #131
Comments
@ederign: The label(s) In response to this:
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. |
/label project/notebooks-v2 |
@ederign: The label(s) In response to this:
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. |
@ederign: The label(s) In response to this:
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. |
/area backend |
Hi, I propose to work on this issue. |
I'm not sure that IP address can identify the client, as it's very common to have a proxy in front of the kubeflow gateway, and we don't really make any requirements about setting any "x forwarded for" headers. I'm really not sure if we can successfully do this, because we can't identify clients. The main thing we can do is probably just ensure that we're not overloading the kubernetes cluster, and we're already doing that largely (by using controller-runtime client so get/lists are cached). |
I think there's already an issue for it, but we should probably consider doing some kind of caching (at multiple layers of the stack), as that will probably be more useful. That is, if two people make the exact same list request within a few seconds of each other they should just be given the same answer. |
Respond to status with information about "retry after time" so we can implement rate liming in the future.
The text was updated successfully, but these errors were encountered: