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 [email protected] 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.