Bug 1303232

Summary: [RFE] Supporting non HTTP[s](80/443) traffic routes [traffic ingress]
Product: OpenShift Container Platform Reporter: Eric Jones <erjones>
Component: RFEAssignee: Mike Barrett <mbarrett>
Status: CLOSED DUPLICATE QA Contact: Johnny Liu <jialiu>
Severity: high Docs Contact:
Priority: high    
Version: 3.1.0CC: aos-bugs, ccoleman, creynold, eparis, jokerman, mmccomas
Target Milestone: ---Flags: erjones: needinfo? (ccoleman)
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-02-22 16:09:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Eric Jones 2016-01-29 21:44:32 UTC 
Description of problem:
Allow services/applications to bind to not http(s) ports such as an application hosting content at 80 and 443 but have a rest cli at 8180. We should be able to expose multiple ports from one service or expose more than one service, and its port, on a single pod.

Additional info:
Currently the view point for this issue is that we do not support non-http(s)/non-SNI but that it is loosely possible by customizing the router. But there has also been disagreement on the viability of actually exposing these because of how ports should be handled or are handled.

It has been discussed what needs to be modified, the NodePort, which may or may not be non-functional, the HostPort, or the HostNetwork.

I was able to find a trello card [0] that discusses this topic.

[0] https://trello.com/c/9TXvMeS2/54-13-supporting-non-http-s-80-443-traffic-routes-traffic-ingress
Comment 3 Eric Paris 2016-02-01 14:42:14 UTC 
https://trello.com/c/9TXvMeS2/54-13-supporting-non-http-s-80-443-traffic-routes-traffic-ingress
Comment 5 Clayton Coleman 2016-02-07 19:40:20 UTC 
Our default answer for exposing ports in NodePort.  We should ensure we have clear requirements about what the gaps are in the existing NodePort solution (claiming known ports) so that whatever is built on top of service node ports are clear.
Comment 9 Dan McPherson 2016-02-22 16:09:16 UTC 

*** This bug has been marked as a duplicate of bug 1287471 ***