On Wed, Dec 15, 2010 at 03:10, Andrew Forgue <[email protected]> wrote:
> On Dec 13, 11:27 pm, Daniel Pittman <[email protected]> wrote:
>> > diff --git a/lib/puppet/network/resolver.rb 
>> > b/lib/puppet/network/resolver.rb
>> > new file mode 100644
>> > index 0000000..9165efb
>> > --- /dev/null
>> > +++ b/lib/puppet/network/resolver.rb
>> [...]
>> > +    Puppet.debug "Searching for SRV records for #{hostname}"
>> > +    rrs = resolver.getresources(hostname, Resolv::DNS::Resource::IN::SRV)
>>
>> Doesn't this resolve the label 'example.com', where you wanted
>> '_puppet._tcp.example.com'?
>
> I did not change the default for Puppet[:server] so if the configured
> server does not have SRV records, it will just return the hostname
> itself.  I did this to keep compatibility and not change any
> defaults.  Ideally the default for Puppet[:server] would be
> _puppet._tcp.$domain but until that's the case, you need to specify it
> manually in the config file (or cmd line).

That sounds like a bad implementation of service discovery to me; that
is violating the spec (which calls for resolving
_service._proto.whatever) out of the box, and requires manual
configuration to make it actually valuable.

Misusing the service discovery protocol for the sole purpose of
providing client-side load balancing sounds like a bad choice to me -
especially because we then need to support this oddball interface for
a whole bunch of years.

I would oppose this proposed implementation, but would support one
that did appropriate SRV lookups on either the hostname supplied, or
the domain name, to locate the puppet master - and had an appropriate
fallback to talking directly to the supplied hostname if it can't be
resolved.

Regards,
    Daniel
-- 
✣ Daniel Pittman            ✉ [email protected]            ☎ +61 401 155 707
              ♽ made with 100 percent post-consumer electrons

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/puppet-dev?hl=en.

Reply via email to