On Feb 8, 2013 8:35 PM, "Jo Rhett" <jrh...@netconsonance.com> wrote: > > So PL has been telling us that puppet kick is dead, and to shift to mcollective agent. The idea of getting away from 800mb puppet agents has a lot of appeal. Here's some advisories and bugs to watch before you make the shift. If you are preparing to make the shift, you may want to go to these bugs and vote for them, since you'll be a lot happier when they are fixed. > > 1. You can't control puppet daemon without killing puppet mid-run http://projects.puppetlabs.com/issues/19153 > > So when you shift away from puppet daemon to cron-run puppet you're going to say "Hey! I know how to do this!" > > service { 'puppet': > ensure => stopped, > enable => false, > require => File['/etc/cron.d/puppet','/etc/puppet/puppet.conf'], > } > > Well, not so fast. On CentOS, it turns out that "puppet agent --test" works fine, but "puppet agent --onetime" is caught by this and killed by itself mid-run. Depending on the host and your dependency trees, this could be very early or very late in the run. No kidding, you have to deploy 'monit' or something similar to ensure your puppet agents aren't running in daemon mode. >
As long as you run them with --no-daemonize you should be safe. Which is one of the things --test turns on. > 2. No classes file. http://projects.puppetlabs.com/issues/show/7917 > > Mcollective agent for puppet gives you some really nice features, like being able to do things against hosts on which certain puppet classes are applied. For instance, to update all webservers you might do something like: > $ mco puppet agent runonce --batch 5 --with-class webserver > > Unfortunately, once you shift away from puppet agent, puppet no longer writes out the classes.txt file. So this method of filtering your mco commands isn't available. > Hmm, I'm quite sure that file is written out for us at least. But can check. > 3. There's no documented best way to run puppet from cron. > > I suspect PL hasn't put down a recipe for this since Puppet Commander hasn't been updated to work with Puppet 3 yet. That's probably the answer, but it's not available yet. This might be a good reason to wait. > > We settled on the many-year-old version of running it from cron with fqdn_rand(30). Given the numerous problems with the cron resource, we did this in a separate cron.d file like so: > > # two variables to control puppet run time > $first_minute = fqdn_rand(30) > $second_minute = $first_minute + 30 > file { "/etc/cron.d/puppet": > owner => root, > group => root, > mode => 0444, > content => template('puppet/cron-puppet'), > require => Package['puppet'], > } > > There might be a better way, but I couldn't find it. I'd really like to see a "best practice" recommendation from PuppetLabs. > That is how we run it as well. Although we also have a small wrapper script around it to allow us to disable cron runs but still allow manual runs. -- 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.
