-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Write an E2E test that stresses route creation. #3287
Comments
Scale-from-zero test seems to do that exactly. So, we have the test. |
So with my changes today on my bigass GKE cluster I am able to pass the test reliably at 50 and reliably fail it with 503 at 60 services (ScaleFromZero performance test). |
I don't think the scale-from-zero test stresses what I'm after here. I'd like to come up with a test that creates a new route and immediately hammers it (quicker than the usual 1 sec retry) and reports how many 404s/503s happen before it eventually works. We should be able to eventually enable that test and not need retries throughout our tests. That's the goal at least. /assign |
Not working on this /unassign |
/close We have scale/scale-N tests that aren't flakey now. |
@tcnghia: Closing this issue. 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. |
We already have an E2E test that tests route creation. However, we see a large amount of "503: no healthy upstream" directly after creating a route. See #2464 for more in-depth information and analysis on that.
Instead of dealing with failures across the board, I'd like to come up with a test that stresses this scenario specifically. We can then either work to fix that test for good or live with the 503s once we root caused them.
For the meantime, I'd like to propose to retry these errors throughout our test suite as proposed in #3286.
The text was updated successfully, but these errors were encountered: