FAQ
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.

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.

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.

--
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.

--
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+unsubscribe@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.

Search Discussions

  • Jo Rhett at Feb 9, 2013 at 2:24 am

    On Feb 8, 2013, at 10:44 AM, Jo Rhett wrote:
    2. No classes file. http://projects.puppetlabs.com/issues/show/7917
    This was actually operator error on my part. Not an issue.

    --
    Jo Rhett
    Net Consonance : net philanthropy to improve open source and internet projects.



    --
    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+unsubscribe@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.
  • Erik Dalén at Feb 9, 2013 at 1:28 pm

    On Feb 8, 2013 8:35 PM, "Jo Rhett" 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+unsubscribe@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.
  • Ellison Marks at Feb 10, 2013 at 9:05 pm
    We use mco puppet runall 1 (our master is slightly anemic) in an every hour
    cron job. We have few enough hosts that they can all run within the hour.
    It's not quite as nice as the commander, as the commander would start
    running them all immediately after the last one was done, but it works for
    our purposes.
    On Friday, February 8, 2013 10:44:51 AM UTC-8, Jo wrote:

    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.

    --
    Jo Rhett
    Net Consonance : net philanthropy to improve open source and internet
    projects.
    --
    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+unsubscribe@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.
  • R.I.Pienaar at Feb 10, 2013 at 9:36 pm

    ----- Original Message -----
    From: "Ellison Marks" <gtyaoi@gmail.com>
    To: puppet-users@googlegroups.com
    Sent: Sunday, February 10, 2013 10:05:25 PM
    Subject: [Puppet Users] Re: warnings for those shifting from puppet kick to mcollective

    We use mco puppet runall 1 (our master is slightly anemic) in an every hour
    cron job. We have few enough hosts that they can all run within the hour.
    It's not quite as nice as the commander, as the commander would start
    running them all immediately after the last one was done, but it works for
    our purposes.
    We'll soon release a new commander :) the runall logic is in a utility
    class we'll pretty much just call it in a loop

    I am looking for some big sites using the new agent to get some feedback on
    the new runall logic so we can be sure it's logic doesnt have the same issues
    as the previous commander

    --
    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+unsubscribe@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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedFeb 9, '13 at 1:05a
activeFeb 10, '13 at 9:36p
posts5
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase