Hi Willy,
> 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.
I agree that the alias or external identifier seems a bit tricky, but
if it defaulted to the server name and all the cli APIs matched server
names first and fell back to the external identifier it might work
without an identifying character. Most of the use cases I can think of
either wouldn't set it (so it would always == id) or would set it to
something different from the id.
>>
>> 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.
I think the alternative approaches we've talked about are more
promising (especially on large farms), but I'll update when the proof
of concept I'm working on either works or not.
>
>> 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 ;-)
I'm going ahead and working on a patch to the service discovery system
that maintains this mapping externally, but without ports in the
server state file it has to do a lot of bookkeeping in its own state
file (Synapse has had a server state file for a long time heh). I'm
working on a proof of concept that does the bookkeeping locally but
I'm working on it in spare time so not very quickly...
>> 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).
Yes I agree this would be an important detail.
>> 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!
Indeed, but I think if it's relatively easy to treat server ids as
separate from the discovery service's notion of a server id that would
be a reasonable abstraction layer to implement it at?
> 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.
Most tools I'm aware of have the notion of a "service" which typically
corresponds to backend/farm (or at least this is how Synapse and most
usages of consul I've seen do it). More complex cases map these to a
frontend + ACL -> multiple backends in HAProxy, for example a single
shared frontend that routes to backends via a "X-service-name" header
or a single frontend which routes to multiple backends to achieve
failover.
I'm not aware of a service discovery tools which group all the servers
into one big backend and do use-server or lua or something, but that's
maybe theoretically possible.
-Joey
