On Fri, 2012-05-11 at 09:39 -0700, Daniel Sauble wrote: > Another problem is that if you move services around, you have to > update puppet.conf on all nodes that use that service. For example, if > you migrate your master to a new host, you have to update puppet.conf > on every agent that uses that master. What Puppet Sites provides is a > service registry that allows you to store this information in a > central location. Your agents retrieve service connection information > from the service registry. So, if your master switches to a different > host, all you need do is update the host in the service registry, and > all your agents will pick up that change automatically.
Daniel, Sorry for chiming in late, but I'm just catching up on this discussion. I didn't see explicit mention of it one way or the other, but I would hope that whatever mechanism you are using for the service registry will support some type of inheritance mechanism for assigning the configuration settings at fairly arbitrary levels/grouping and not just globally with per-host overrides. At $WORK we are a multi-tenant environment and differing customer needs mean that there is a potential for potentially significant Puppet configuration variances from environment to environment. For instance, one customer may have their own Puppetmaster environment for catalogs/files, but share the common CA, while most other customers use a shared set of Puppetmasters. We have created a "$customer" variable within Puppet (available with every host) that we use with Hiera to select out any per-customer settings. We aren't currently but may even select Puppetmasters based on datacenter (so, $customer and $datacenter as either/or selectors with a likely global default). Having to manage customer-wide variances per-host would quickly get pretty unmanageable. Right now our puppet.conf files are generated via templates (with data pulled from Hiera) and deployed by Puppet to take into account any variances. I like the Sites concept, but it would have to account for a similarly high degree of flexibility to be something we'd be able to use. Thanks, Sean -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
