Issue #3669 has been updated by Silviu Paragina.

The main problem, for load balancing on fail, aren't the manifests but related 
files. I've noticed that sometimes loading facts and/or files fails despite the 
manifest being ok. I haven't had the time to investigate that issue further, to 
check if it's a timeout or something else, but this may lead to some nasty 
problems, when, for example, a fact isn't loaded. 

So imho:
* the client should be able to find out if the error is a puppet server error 
(no memory, timeout etc) or configuration one(missing files or any other type 
of user/administrator error)
* I'm not sure if the client should send all the requests in a puppet run to a 
single server or should load balance each one. Load balancing each request 
sounds great, but in fact may do more damage than good as it adds an 
authentication overhead for each request (just wanted to point out this in any 
case).
* if the client encounters a puppet server error it should try to repeat the 
request on another server. 

Is this kind of behavior implementable without changing half of puppets 
infrastructure or is it far fetched. Or it may lead to bad behavior I have not 
foreseen?

Maybe this should be a different ticket, but the note above, about the manifest 
code not being the same, made me think about the synchronization issues between 
servers. Most notably that there should be some type of manifest version 
checking on the client, in case let's say a "git pull" fails on only one 
server. If i remember right the client can currently tell the version of the 
currently applied manifest. 
----------------------------------------
Feature #3669: Make puppet honor DNS SRV records
http://projects.puppetlabs.com/issues/3669

Author: Martin Marcher
Status: Accepted
Priority: Normal
Assigned to: 
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