Hi Tait
A few comments inline:
1. Reloading with SRV records ignores server-state-file
> - While this is not a huge deal, it does mean that the backend in
> question becomes unavailable when the proxy is reloaded until the SRV and
> subsequent A records are resolved
>
- I understand that the point of these records is to dynamically build
> the backend, and populating servers from outdated and potentially invalid
> information is not ideal, but it might be nice to seed the backend before
> the first SRV query returns
>
This should not happen and it's a known issue that we're working on.
> - Below is the related config since it is very likely that I have
> misconfigured something :)
>
> globals
> ...
> server-state-base /var/lib/haproxy
> server-state-file state
>
> defaults
> ...
> load-server-state-from-file global
> default-server init-addr last,libc,none
>
> ...
>
> resolvers sd
> nameserver sd 127.0.0.1:9999
>
> backend dynamic
> server-template srv 5 _http._tcp.serviceA.tait.testing resolvers sd
> resolve-prefer ipv4 check
>
> 2. Additional record responses from the nameserver are not parsed
>
This is true, by design.
> - This just means that any servers that are populated from the SRV
> records require a second round of querying for each of the hosts after the
> fqdn is stored. It might be more efficient if these records are also parsed
> but I can see that it might be pretty challenging in the current DNS
> resolver
> - Only reason I thought of this was to try and reduce up the time it
> takes to populate the backend servers with addresses in an effort to lessen
> the effects of #1
>
Actually, I tested many DNS server and some of them simply did not send the
additional records when they could not fit in the response (too small
payload for the number of SRV records).
Technically, we could try to use additional records if available and then
failover to current way of working if none found.
> I'm happy with the workaround I'll be pursing for now where my SD service
> (that originally was going to be a resolver and populate via SRV records)
> is going to write all the backend definitions to disk so this is not a
> pressing issue, just thought I'd share the limitations I discovered. My
> knowledge of C (and the internal workings of HAproxy) is not great
> otherwise this would probably be a patch submission for #1 :)
>
> Tait
>
>
I'll check that for you. (In the mean time, please keep on answering to
Aleksandar emails, the more info I'll have, the best).
Baptiste
