-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
ci: Set hubble.relay.retryTimeout=5s #32066
Conversation
I noticed CI seemed to flake on hubble-relay being ready. Based on the logs it was due to it being unable to connect to it's peers. Based on the sysdump the endpoints did eventually come up, so I think it just needs to retry more often, and the default is 30s so lower it to 5s in CI. Signed-off-by: Chance Zibolski <chance.zibolski@gmail.com>
I can see it specified the right option but the test succeeded and there's no sysdumps; so I can't actually confirm it was added to the configmap, but it should be. |
a49b5e5
to
d32f835
Compare
Removing the tmp commit so this can be marked as ready for review. |
/test |
@chancez should we also backport to stable, to prevent similar CI flakes there? |
@julianwiedmann seems reasonable and easy? Do we just apply the necessary labels for that? |
yep. Looks like the |
I noticed CI seemed to flake on hubble-relay being ready. Based on the logs it was due to it being unable to connect to its peers.
Based on the sysdump the endpoints did eventually come up, so I think it just needs to retry more often, and the default is 30s so lower it to 5s in CI.
An example of such a CI run: https://github.com/cilium/cilium/actions/runs/8729875690/job/23952676116?pr=31973.
I've added some temporary commits to test the changes, which I'll remove after I verify the correct options are being used.