Bug 1046150 - Alias not inherited for new HAProxy gears on HA apps
Summary: Alias not inherited for new HAProxy gears on HA apps
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Node
Version: 2.0.0
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
: ---
Assignee: Luke Meyer
QA Contact: libra bugs
URL:
Whiteboard:
Depends On: 1046196
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-23 20:58 UTC by kotarusv
Modified: 2014-01-03 19:46 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1046196 (view as bug list)
Environment:
Build Name: 19237, REST API Guide-2-1.0 Build Date: 09-12-2013 16:09:51 Topic ID: 25090-566975 [Latest]
Last Closed: 2014-01-03 19:46:18 UTC
Target Upstream Version:


Attachments (Terms of Use)

Comment 2 Bilhar 2013-12-23 21:43:10 UTC
kotarusv@gmail.com, can you please point me to what you would like to see changed in the docs? I'm not sure if I understand what exactly the problem is here.

Is this BZ supposed to be for the docs, or for the product? Docs REST API Guide or the OSE REST API?

Any information will be very helpful so that we can address this BZ. 

Thanks.

Comment 4 Luke Meyer 2013-12-26 15:42:02 UTC
Just to be up front, I am still coming up to speed on the routing SPI, but there isn't likely to be anyone else around until the new year who knows the subject better.

That said, I think this is working as designed. It doesn't look to me like all of the HAproxy gears are intended to be equivalent to the head gear. An application alias is not configured at the front end proxy for non-head HAproxy gears, nor is the application's name itself. I don't think this matters greatly because the routing SPI exposes the port-proxy public gears, and it seems clear that this is what the router is expected to use, not the standard ports that go through the web or websockets proxy.

For example, I set up an HA app:

$ rhc app show -a scaledruby19 --gears
ID                       State   Cartridges           Size  SSH URL
------------------------ ------- -------------------- ----- ------------------------------------------------------------
--------------   
52b3b42fa50ac44ff5000154 started mysql-5.1            small 52b3b42fa50ac44ff5000154@52b3b42fa50ac44ff5000154-demo.apps-20.example.com   
52b3b42fa50ac44ff5000151 started ruby-1.9 haproxy-1.4 small 52b3b42fa50ac44ff5000151@scaledruby19-demo.apps-20.example.com
52bc4085a50ac46172000006 started ruby-1.9 haproxy-1.4 small 52bc4085a50ac46172000006@52bc4085a50ac46172000006-demo.apps-20.example.com   

... and looked at the messages coming through the SPI. Here's one for the second HAproxy gear:

:action: :add_gear
:app_name: scaledruby19
:namespace: demo
:public_port_name: haproxy-1.4
:public_address: 10.0.0.2
:public_port: '38102'
:protocols:
- http
- ws
:types:
- load_balancer
:mappings:
- frontend: ''
  backend: ''
- frontend: /health
  backend: /configuration/health

I notice it just has address and port; no hostname info (the app_name and namespace are only for identifying purposes). A load balancer can route any request there, whether for alias, regular app name, or anything made-up. The LB could even route directly to non-HAproxy gears/cartridges.

Here's the SPI message for adding an alias:
:action: :add_alias
:app_name: scaledruby19
:namespace: demo
:alias: foo.com

You could handle alias routing either by having the router resolve it to the app name and then route that, or by directly binding the alias to the routing to the IP and port that was given for the app HAproxy gears. Either way I think the intent is to route the alias directly to the public gear ports, not the node web proxies.

Since there's no need to go through the node web proxies, there's not really any point in configuring them, right? Am I missing anything?

Comment 5 Luke Meyer 2014-01-03 19:46:18 UTC
rchopra's comment on the upstream clone of this bug:

----------------------------------------------------------------------

As per the latest code, gear info gives the endpoint information if 'include=endpoints' is added to the REST request.

The alias is configured with only the head gear. The reason is that the alias is assumed to be pointing to the app's DNS entry. And since the app's DNS entry contains just one IP address (as of today's known dns plugins), having the alias entry for the other haproxy gear makes it pointless. 

For HA apps (with/without multiple haproxies), the design assumes that traffic will be routed directly to the endpoints through the router.

If we were to include the alias for subsequent haproxy gears as well, we would have to consider front-end becoming a load balancer rather than just a proxy (so that we do not run into conflict if two haproxy gears happen to end up on the same node).

----------------------------------------------------------------------

I confirmed that the ?include=endpoints parameter on the REST API does return the endpoints for OSE 2.0 (e.g. curl -k -u demo:changeme 'https://broker.hosts.ose20.example.com/broker/rest/domains/demo/applications/myscaledapp/gear_groups?include=endpoints'), so that is an alternate way to get the direct gear endpoints (instead of the routing SPI listener).

Feel free to re-open the bug if you disagree, but this functionality seems to be working as designed.


Note You need to log in before you can comment on or make changes to this bug.