-
Notifications
You must be signed in to change notification settings - Fork 792
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
Add retryable HTTP client to image-awaiter #1830
Conversation
to image-awaiter so it doesn't bomb on startup if network is not already available
Thanks for submitting your first pull request! You are awesome! 🤗 |
This LGTM @bleggett, I made a comment about the docker image tag, but if you agree I think this can be merged right away! I appreciate how you described the PR clearly and provided example log output into to help it seem plausible it actually works as intended! I updated the title to not include the "fix issue #number" and instead added that to be part of the PR description, which will make GitHub automatically close the issue if this PR is merged, and also make for more conformant changelogs within this repo. |
Woop woop! Thank you @bleggett for your work, this is something I would have find troublesome to do as I'm a Golang beginner!!! ❤️ 🎉 |
@consideRatio thanks - I accidentally left in a redundant build step in the |
Uses https://pkg.go.dev/mod/github.com/hashicorp/go-retryablehttp which is a drop-in compatible wrapper around the default Go http client.
Will fix issue where
image-awaiter
never becomes healthy when deployed in a cluster with a service mesh - since the service mesh uses an init container to configure pod networking, the network might not be ready to route connections whenimage-awaiter
tries to make a connection on startup, soimage-awaiter
should be a good resilient HTTP client and at least retry a few times.Example using the retry settings of 5 retries:
EDIT: Fixes #1793