Description of problem: When setting up an External Load Balancer, if you create a listener (that form's routes based on the Host) the node's do not know about, the HA prefix or suffex which causes a HTTP 302 redirect loop looking for the getting_started.html page. How reproducible: Very Steps to Reproduce: 1. See https://bugzilla.redhat.com/show_bug.cgi?id=1128856#c3 Actual results: 302 re-direct loop to the getting_started.html page. Expected results: Node should know about HA endpoints and be able to route to applications (head gears) based on the ha endpoints provided. - Note: Routing in this was may not be recommended, way to route to applications however http://openshift.github.io/documentation/openshift-pep-005-available-web.html#openshift-router-component is not clear on the recommended routing method. Additional info: Another solution to this is to for HA application to have an Alias, thus allowing for the node to know about the route.
Without this, the routing layer is forced to route to the port proxy as specified in the PEP, bypassing the httpd frontend. Since httpd frontend access is the main thing that prevents gears idling, the routing layer implementer must ensure in some other way that idling doesn't occur on the LB gears of the HA app, which is a major gotcha. This whole issue could be avoided if the routing layer could forward-proxy ha- app requests unmodified and have them routed to the LB gear on a node just like an alias would be. I think this will be more intuitive to implement.
(Just notes) Implementing this is a bit tricky for a number of reasons. I think the best approach would be for the ha- alias to actually be added as an alias from the broker/mongodb perspective. This would resolve issues like: 1. The first gear is created without knowing the app will be HA, so you have to go back and add the alias later. 2. The broker currently doesn't give nodes any way of knowing what the ha- alias would be. Since it's configurable, this would have to be an added parameter that's added to the gear env vars if we were going to have it added only to the frontend, since that's basically all the frontend has to go from (this would also be painful due to #1). 3. HAproxy gears after the first two also need the alias. 4. It might possibly need a custom SSL cert. This is all trivially accomplished by just adding an alias. Only problem points with this approach: 1. Needs to be exempted from alias validation as it will probably be in the cloud domain. 2. The user will see it as an alias, and could also delete it, shooting themselves in the foot. This may just be acceptable, or we might need to protect it somehow.