Hi Joey,
On Thu, Jun 22, 2017 at 04:20:36PM -0700, Joseph Lynch wrote:
> 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?
That makes me think about the notion of alias I was thinking about and
I still don't feel much comfortable with it because that would cause
trouble if there are overlapping names. But we can simply have a way
to indicate that we're asking for the external name instead of the
internal one. It might be by forcing external names to start with a
specific character, it might be via the use of a different delimitor,
via a specific option, I think we have plenty of choice.
> 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?
If that can be useful to you, that's trivial to do. In fact we could even
imagine "get servers {by-addr|by-name|by-id|by-state} <backend> [value]"
depending on the type of lookup.
> 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)?
That's the question I'd expect to ask you ;-)
> 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.
And on the CLI. We could imagine a set of extra commands to make life
easier for service discovery, like "show farm <b>" listing the servers
in an easy to process format (internal id, internal name, external name,
address, enabled/disabled).
> 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.
Don't worry about the ease to do it in haproxy. Most of the bad designs
we've accumulated over time were caused by trying to do something quick
and dirty. Putting more thoughts on the change to ensure it's properly
done and perfectly matches the use case is much better, it will save us
from having to deal with non-natural uses causing side effects. The cost
of writing 50 more lines is nothing compared to the difficulty to solve
problems purposely created to work around certain limitations!
I was wondering about something else, do service discover tools really
have the notion of the backend/farm/whatever, or do they manipulate
globally unique IDs for servers ? I'm just trying to think whether we
need to support looking up a server via its public ID regardless of
the backend name or if it's better to do it within a backend as is
done today.
Willy
