[distcc] Re: Bug#214621: distcc: better handling for round-robin DNS

[Martin Pool]

On  7 Oct 2003, Zygo Blaxell <zblaxell at genki.hungrycats.org> wrote:

> It would be nice if distcc would better support the use of round-robin DNS
> aliases for volunteer hosts.  Ideally I would have all my volunteer hosts
> listed in a single DNS entry named "distcc", and DISTCC_HOSTS would be
> simply "distcc,lzo" (in reality I have these machines broken down by
> FSB RAM speed into a few aliases, but the principle is the same ;-).
> 
> Here are the wishes:
> 
> 1.  Error reporting should include the IP address as well as the hostname.
> Currently I get error messages like "failed to distribute to distcc",
> but "distcc" could be any one of as many as 30 machines.  I have to grep
> through either the output of DISTCC_VERBOSE to find out what machine it
> was actually having problems with.
> 
> 2.  Locking, backoff, and scheduling should be done by IP address.
> Currently if any single volunteer fails, distcc will drop all of the
> IP addresses associated with the name.

Thanks for your report.

This has already been discussed a couple of times on the list.

If we were going to support round-robing DNS in this way, I agree that
both your wishes should be done.

However I don't think using rr dns to list hosts is a good idea, for a
couple of reasons:

A fair number of machines have multiple A entries because they have
multiple network interfaces.  (In particular, I use one such in my
build farm.)  We wouldn't want them to get twice as many jobs, or to
interfere with sending the jobs over the best interface.

There's no space to specify relative speed of the machines or other
relevant options.  But this is not a very strong objection because
normally little configuration should be needed.  

Using multiple names with different options for each is an intruiging
idea, but once you start putting configuration like that on each
client you've lost much of the benefit.

If this is going to be stored in DNS, then using something like the
SRV record would be a better solution.  I don't see any way in which
SRV is worse than A, and it avoids overloading the mechanism.

Alternatively I can just be lazy and suggest that you fetch
/etc/distcc/hosts over HTTP, rsync or some similar mechanism.

-- 
Martin