Created attachment 1266776 [details] mypod Description of problem: After less then hour the command oc -n podify port-forward jhenner-pf-experiment 12345 stops being blocking and before exiting says: Handling connection for 12345 E0327 18:29:26.130752 8942 portforward.go:175] lost connection to pod Version-Release number of selected component (if applicable): atomic-openshift.x86_64 3.4.1.10-1.git.0.c96aed3.el7 rhel-7-server-ose-3.4-rpms atomic-openshift-clients.x86_64 3.4.1.10-1.git.0.c96aed3.el7 rhel-7-server-ose-3.4-rpms atomic-openshift-clients-redistributable.x86_64 3.4.1.10-1.git.0.c96aed3.el7 rhel-7-server-ose-3.4-rpms atomic-openshift-docker-excluder.noarch 3.4.1.10-1.git.0.c96aed3.el7 rhel-7-server-ose-3.4-rpms atomic-openshift-dockerregistry.x86_64 3.4.1.10-1.git.0.c96aed3.el7 rhel-7-server-ose-3.4-rpms atomic-openshift-excluder.noarch 3.4.1.10-1.git.0.c96aed3.el7 rhel-7-server-ose-3.4-rpms atomic-openshift-master.x86_64 3.4.1.10-1.git.0.c96aed3.el7 rhel-7-server-ose-3.4-rpms atomic-openshift-node.x86_64 3.4.1.10-1.git.0.c96aed3.el7 rhel-7-server-ose-3.4-rpms a How reproducible: 4/4 Steps to Reproduce: 1. oc create -f mypod 2. oc -n podify port-forward jhenner-pf-experiment 12345 & 3. while sleep 1; do date | nc localhost 12345; date; done | tee /tmp/log Actual results: Timeout or broken pipe in less then hour Expected results: command doesn't timeout Additional info: I have tried to add streamingConnectionIdleTimeout: 0 to /etc/origin/node/node-config.yaml on the node where I run the pod, restarted the node but it doesn't seem to help.
Seth, can you verify that this is the same fundamental issue that we previously investigated related to exec? https://bugzilla.redhat.com/show_bug.cgi?id=1382730 If so, we should duplicate this bug on that referenced item and treat as RFE.
Yes this is the same issue. Long running port-forward/exec commands are really indicative of trying to implement a bad pattern on top of Kubernetes. I'd be interested in understanding the use case here. There is probably a better way. *** This bug has been marked as a duplicate of bug 1382730 ***
(In reply to Seth Jennings from comment #2) > Yes this is the same issue. > > Long running port-forward/exec commands are really indicative of trying to > implement a bad pattern on top of Kubernetes. I'd be interested in > understanding the use case here. There is probably a better way. > > *** This bug has been marked as a duplicate of bug 1382730 *** Well we have DB and webserver in openshift and have need to connect to the DB for some purposes during automation testing. Tests are taking quite a long time, but the need of exposing the port for out tests is temporary, so I think it is a valid use-case of oc port-forward. Especially when the other solutions: https://docs.openshift.com/container-platform/3.4/dev_guide/getting_traffic_into_cluster.html#using-externalIP seem to be far more complex to set-up as I would have to apply for IP range allocation for every OpenShift cluster we deploy for the testing purposes, or I would have to be setting-up tunnels anyway.