Puppet users - Feb 2013 - warnings for those shifting from puppet kick to mcollective

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.

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.

On Feb 8, 2013 8:35 PM, "Jo Rhett" <jrhett@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+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.

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.

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