Hi Willy, > OK so if we add a string as the external identifier (let's at least > give a name to this thing) and the ability to lookup by transport > address, you have everything : > - the mesos/kubernetes identifier directly accessible > - the IP:port directly accessible > > Did I miss anything ?
An external identifier that socket commands can be passed as an acceptable <server> would definitely solve the problem. I guess by default the external identifier can just be the name, and we'd prefer matching servers by name before external_identifier? An alternative we could add a lookup function that returns server names matching an address. This would turn current single call enable/disables into two socket commands (one to find the server ids and the next to send the command to the right server ids) but would be reasonably clean from the point of view of not having to modify so many CLI apis. Maybe something like: get servers <backend>/<address> Automation could then lookup the server id from the address and then send appropriate commands by existing <b>/<s> CLI interfaces? Actually thinking about this more, why can't the service discovery system just maintain the map of identifier+host+port -> haproxy backend ids which are just numeric and ascending (e.g. s1-20)? The system would just have s1-20, and internally map "2.2.2.2:8080" to "s2". As the discovery system gets updates, it can change the mapping as it needs. It has to have some sort of understanding of which ids are available anyways, so this shouldn't be much extra complexity. Then the only thing we have to solve is showing the host+port in the stats UI, which is probably a pretty straightforward change. I sort of like "this is the service discovery system's job". It means the HAProxy patch is basically only to the stats UI, which is pretty easy to do presumably. -Joey
