Issue #3669 has been updated by Martin Marcher.

Hi,

(DISCLAIMER: I haven't looked at the puppet code at all!)

as for "design decision" I don't think that much of the Puppet design is 
affected. I'd think the naive approach would be to:

* let an admin configure it (say: "srv_record = _x-puppetcluster12") to 
override the default
* provide a default value to look for (regarding the DNS SRV)
* if the "srv_record" config entry is not present and the DNS SRV lookup fails 
in any way (not configured, querying default value, not receiving results) 
proceed in the "old" way

To me that seems like:

* people not using SRV records wouldn't be affected at all
* people that want the new feature can very simply upgrade.

Leads me to one open question:

Behaviour if srv_record *and* server are defined. Options are:

* *fail the puppet client* - least desirable IMHO as one could easily break 
LOTS of machines
* *favor server over srv_record* - just the opposite of the above. It would be 
the conservative option. But that doesn't mean it's a safe option. By still 
using the "old" server I could get unexpected results like erroneously 
decommissioning the puppet.example.org server and the clients still expecting 
it to exist
* *favor srv_record over server* - also not desireable. I could for example 
simply add the srv_record config option and NOT remove the server. Since it's a 
new feature I'd expect it to pick up and probably change the behaviour... (get 
config from a new master)

Another option:

* don't use 2 different config switches, rather introduce *new syntax in the 
server config option* - this would make the config itself slightly more 
"complex" but would ensure that there's no possibility of confusion how puppet 
finds the host to connect to...

Examples:

 server = puppet # old style
 server = SRV:_x-puppet # new style

Personally I'd either use:

* *favor srv_record over server* or *new syntax in the server config option*
----------------------------------------
Feature #3669: Make puppet honor DNS SRV records
http://projects.puppetlabs.com/issues/3669

Author: Martin Marcher
Status: Needs design decision
Priority: Normal
Assigned to: Luke Kanies
Category: 
Target version: 
Affected version: development
Keywords: 
Branch: 


I'd like to be able to define where puppet looks for the master server.

I propose the following:

By default try in the following order:

1. Look for a "_x-puppet._tcp.example.com" SRV record (or any name that you 
think is appropriate, but keep it a SRV record)
2. For backwards compatibility, if no SRV record is present look for 
puppet.example.com as a fallback or any value that is configured in the puppet 
config file

Reasoning:

A System Administrator can easily spread out the load over multiple puppet 
servers in this way or define some split horizon which answers with the 
"correct" hostname to use as a puppet master.

Thanks,
Martin


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" 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-bugs?hl=en.

Reply via email to