-
Notifications
You must be signed in to change notification settings - Fork 4.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
UPSTREAM: 10647 (carry until 10656): increase Kubelet timeouts to 1 hour #3760
Conversation
This makes the Kubelet's read and write timeouts match the master. 10647 isn't going to be merged. Instead, 10656 will finer-grained timeouts based on the type of request, but it's not merged upstream yet. Once 10656 is merged, we can drop this patch.
LGTM, but I'd like a second |
Straightforward, but can't this end up putting pressure on our MaxInFlight limit if we don't timeout connections as often? |
I thought we only had maxinflight set on the API server, which already had a long timeout |
MaxInFlight can already be consumed - the practical difference between "I get a chance every 5 minutes to sneak a request in" and "I get a chance every 60 minutes" isn't much (the solution is to more aggressively limit). We could go to 15 or 20 minutes. What's the 95% build duration? |
Also affects exec lifetime, not just build logs |
And port forward On Jul 18, 2015, at 9:40 PM, Jordan Liggitt notifications@github.com Also affects exec lifetime, not just build logs — |
lgtm [merge] |
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/2779/) (Image: devenv-fedora_2029) |
Evaluated for origin up to 46f9bb3 |
Merged by openshift-bot
This makes the Kubelet's read and write timeouts match the master.
10647 isn't going to be merged. Instead, 10656 will finer-grained
timeouts based on the type of request, but it's not merged upstream yet.
Once 10656 is merged, we can drop this patch.