3. What is the nature and description of the request? > possibility to add a timeout value for oc rsh 4. Why does the customer need this? (List the business requirements here) > When oc rsh , the connection gets lost after approx 60 ~ 120 secs. This is inconvenient while looking for information for that pod and when coming back to shell connection is lost. 5. How would the customer like to achieve this? (List the functional requirements here) 6. For each functional requirement listed in question 5, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. > when setting a timeout option of 600 , the connection will only be lost after 600 secs. 7. Is there already an existing RFE upstream or in Red Hat bugzilla? > N/A 8. Does the customer have any specific timeline dependencies? > N/a 9. Is the sales team involved in this request and do they have any additional input? > N/a 10. List any affected packages or components. > oc cli 11. Would the customer be able to assist in testing this functionality if implemented? > Yes
3.4 now has a --timeout option.
Tested on version: $ oc version oc v3.4.0.34+87d9d8d kubernetes v1.4.0+776c994 features: Basic-Auth GSSAPI Kerberos SPNEGO Server https://openshift-...com:8443 openshift v3.4.0.34+87d9d8d kubernetes v1.4.0+776c994 For `oc rsh --timeout=<time> database-1-3dmoq`, tried time=10, 300, 600. When the terminal is idle for longer than <time> seconds and we come back to the terminal, oc rsh still keeps alive, i.e. does not exit.
About the help info: $ oc rsh -h ... --timeout=10: Request timeout for obtaining a pod from the server ... ... $ oc options ... --request-timeout='0': The length of time to wait before giving up on a single server request ... Above info both hint 'R/request' timeout. IMHO, from intuitive textual reading, I didn't figure out what is the diff of 'timeout' flag in oc rsh from the global 'timeout' flag --request-timeout. Until I read comment 0 scenario, I got the former is about the idle time for oc rsh session. So it is better to update help info of --timeout for oc rsh clearer
Related origin PR: https://github.com/openshift/origin/pull/12231 Related kubernetes PR: https://github.com/kubernetes/kubernetes/pull/38642
Related upstream PR: https://github.com/kubernetes/kubernetes/pull/38642
Right now the current default idle timeout for commands such as `oc rsh` and `oc exec` is 4 hours [1]. This can be changed as part of the cluster config by a cluster admin. I am not sure why your connection was timing out after 1-2 mins, but I recommend updating oc and seeing if you are still having this issue. [1] https://github.com/openshift/origin/blob/master/vendor/k8s.io/kubernetes/pkg/apis/componentconfig/v1alpha1/defaults.go#L303
Closing related pull requests for now. https://github.com/kubernetes/kubernetes/pull/38642 https://github.com/openshift/origin/pull/12231 > 4. Why does the customer need this? (List the business requirements here) > >> When oc rsh , the connection gets lost after approx 60 ~ 120 secs. > This is inconvenient while looking for information for that pod and when coming > back to shell connection is lost. This bug is most likely an issue not directly addressed by the addition of a client-side option to update idle timeouts for streams. Please also see https://bugzilla.redhat.com/show_bug.cgi?id=1314240#c6
Closing this as not a bug for now. Please re-open if problem still exists after updating `oc`
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days