kotarusv, 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.
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.example.com 52b3b42fa50ac44ff5000151 started ruby-1.9 haproxy-1.4 small 52b3b42fa50ac44ff5000151.example.com 52bc4085a50ac46172000006 started ruby-1.9 haproxy-1.4 small 52bc4085a50ac46172000006.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?
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.