Bug 1131642
Summary: | [RFE] Node does not add frontend routes for HA app hostname (with prefix / suffix) | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Eric Rich <erich> |
Component: | RFE | Assignee: | Mike Barrett <mbarrett> |
Status: | CLOSED WONTFIX | QA Contact: | Johnny Liu <jialiu> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 2.1.0 | CC: | aos-bugs, asimonel, jokerman, libra-onpremise-devel, misalunk, mmccomas, nicholas_schuetz, pep |
Target Milestone: | --- | Keywords: | FutureFeature, RFE |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-04-11 20:58:12 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: | |
Embargoed: |
Description
Eric Rich
2014-08-19 18:08:20 UTC
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. |