Puppet

As an addendum, I would propose that randomserver’s default value be false.

Also, I should give credit where due and state that this entire proposal is copied from the way that openvpn does things; to quote from an example openvpn configuration:

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote server-a.example.com 1194
remote server-b.example.com 1194
remote server-c.example.com 1194

# Choose a random host from the remote
# list for load-balancing. Otherwise
# try hosts in the order specified.
;remote-random

I don’t have a strong opinion on this question; what seems both easiest and most reliable to me would be to pick a single server for each run. That is, a single invocation of —onetime would go to a single server, but the server could change after every runinterval.

It also makes sense to me to stick to a single server unless it has a problem, so that we don’t keep trying to hit dead servers (that’s what this “lastserver” variable is about), but I don’t really view that as essential. You could argue that it’s better to try a random server each time so as to quickly redistribute the load after a failure.

How will this work with environments? Isn’t this going to hit exactly the same problem as #1557 ? Where the server may not have any environment information for a given client on requests subsequent to the initial connection?

It shouldn’t be an issue as long as the server is not changed within a run.

Wolfgang,

What you are proposing is very different from the proposal in this Wishlist entry. Also, your request would require major changes to the existing Puppet paradigm. If the ability to combine manifests from multiple sources is very important to you, and you are willing to dedicate a lot of time and money to that feature, then I would suggest you open a new Feature request and/or get in touch with Reductive Labs for paid work.

Cheers,

—Ian

I agree with Ian – that’s a big change, and it shouldn’t be part of this ticket.

You can already get that to some extent by splitting file serving and node management onto separate servers.

this is looks like a important feature for scaling I’m interested for high availability in this case

Think about the multiple certification in this case (http://projects.puppetlabs.com/projects/puppet/wiki/Multiple_Certificate_Authorities)

If I see the last note on that there is also work in progress about that I don’t now if you should include that into this ticket or create a new one?

For the people who care about this issue, would you be satisfied with #3669 and having this be implemented as part of the SRV record work?

I was just looking for a similar feature — but my use case is a little different.

I don’t want round robin — I only want the alternate puppetmasters as failovers if the primary isn’t responding, and then failback when the primary is back up.

If it is possible to incorporate that into this feature, that would be great.

(Our use case, btw, is running puppetd apply from cron.)

Rich, would priorities in SRV records work well enough for that purpose for you?

I’m considering closing this feature request in favor of doing it as SRV records.

This would be highly useful for an implementation we are currently considering where we essentially have tiers of puppetmasters and would like to have a comma delimited list of puppetmasters in the agent config which will be attempted in order, moving up a tier each time.

For everyone commenting on this, please think about whether SRV record support that we’ve merged will suffice for what you need.

Reviewed for triage-a-thon 21-01-2012; ticket looks ok to me for 2.7.9.