We use puppet and a module called vcsdeploy to deploy our modules to the puppet masters using a puppet run on the puppetmaster. We insist that all modules are tagged and so our nodes file fotr the puppetmaster node looks like this: -
node 'puppetmaster' { # ONLY DEPLOY tagged versions to TEST!!! Vcsdeploy { source => 'http://svnserver.practicalclouds.com/repos/puppet/modules/%%NAME%%/tags/%%VERSION%%', path => '/etc/puppet/environments/test/modules/%%NAME%%', provider => 'svn', user => 'user', pass => '######', templates => 'off', } vcsdeploy { 'centrify': version => '1.7', } vcsdeploy { 'wamps_repository': version => '1.1', } vcsdeploy { 'weblogic': version => '4.5', } vcsdeploy { 'motd': version => '1.0', } vcsdeploy { 'ntp_client': version => '1.0', } You can find out more about vcsdeploy either on the puppet forge http://forge.puppetlabs.com/pclouds/vcsdeploy or here http://www.practicalclouds.com/content/guide/pclouds-vcsdeploy-deploy-stuff regards Dave On Wednesday, May 2, 2012 3:18:28 PM UTC+1, Scott Merrill wrote: > > For folks with multiple Puppet Masters, how are you pushing out > manifest and module updates to them? > > We intend to use Subversion for our version control. Obviously one > option would be to have each Puppet Master perform a checkout of the > svn repo. We could schedule periodic updates via cron. Or we could use > a post-commit hook to rsync the updates out from the repo to each > Puppet Master. > > What are you doing? What works well, and what headaches have you > experienced? > > Thanks, > Scott > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.