[distcc] PATCH: multi A records / very small timeout on connect

[Martin Pool]

On 22 May 2003, mlafon at arkoon.net wrote:

> Included is a two features patch for distcc 2.4.1.
> 
> - Avoid timeout on firewalled hosts by using a non-blocking connect() with a
> very
>   small timeout (currently 1 sec but could be easily set using an environment
> variable)
> 
> - Handle multi A records by expanding the hosts list on startup. This allows
> distcc
>   to use a shared hosts list via a simple DNS entry
> (farm.domain.com).

Thanks for the patch.

Code that is so ridiculously deeply indented (past the 60th column!)
is generally a strong sign that it needs to be split up into smaller
functions that are easier to read and verify.  I can't merge that as
it is.

I am OK with the general idea of a timeout on connect() and doing
using select().  I will add something like that shortly; there's no
need to change the patch.

I know I originally liked the idea of using multi A records to
indicate host lists but now I am less sure it's the right way to go,
for a few reasons

 - DNS zones are often not under the control of developers; needing
   the hostmaster to change things to set the list of build machines
   is probably not practical for all environments.

 - Some machines may legtimately have multiple addresses, without
   needing to get proportionally more jobs.  One of the machines I
   build on right here has two NICs and two A records, because it acts
   as a gateway.   In the current code this just works: because of
   intelligence in the client resolver we connect to the inside
   address first.

 - Storing A addresses repeatedly is kind of ugly; if people move a
   machine things can be messy.

I'd be more amenable to supporting SRV records, which avoid at least
the second two problems.

mDNS Rendezvous technologies possible avoid all three of them -- any
machine can register to join a group without needing to control the
nameserver.  

Whether that's a good thing or not depends on your point of view.
Perhaps you don't want your jobs distributed to random machines that
just happen to be on your broadcast domain.

In addition there are some incidental problems with the way you wrote
it:

 - Expanding hostnames to IP addresses before calling SSH can change
   its behaviour e.g. by making host keys or config sections not
   match. 

 - It breaks RFC2553 support.

 - _new_hostdef doesn't create a new hostdef.

-- 
Martin