increasing frequency of puppet agent runs during initial deployment?

104 views
Skip to first unread message

markber...@gmail.com

unread,
Jul 28, 2014, 2:57:58 PM7/28/14
to puppet...@googlegroups.com
I'm beginning to use Puppet, and I'm looking for suggestions for the
best way to have 'puppet agent' run very frequently during the initial
deployment phase on a new server.

In our environment, there's one local puppet module that's called in the
'post' stage. This module essentially depends on all other services and
local configurations on the server.

Reaching that stage on a newly deployed server takes serveral iterations
of 'puppet agent'.

Each client calls the puppet agent as a cron job, every 30 minutes. That's
fine after machine is fully configured, but means that there's a long
interval between kickstarting a new machine and having it reach a
usable state.

Essentially, I'd like the calls to 'puppet agent' to loop continuously
(with a very short pause) until classes in the 'post' stage have met
their requirements and executed once, at which time the server is fully
configured and puppet can be run at the normal 30-minute interval.

Any suggestions?

Thanks,

Mark

Christopher Wood

unread,
Jul 28, 2014, 3:20:33 PM7/28/14
to puppet...@googlegroups.com
On Mon, Jul 28, 2014 at 12:53:03PM -0400, markber...@gmail.com wrote:
> I'm beginning to use Puppet, and I'm looking for suggestions for the
> best way to have 'puppet agent' run very frequently during the initial
> deployment phase on a new server.
>
> In our environment, there's one local puppet module that's called in the
> 'post' stage. This module essentially depends on all other services and
> local configurations on the server.
>
> Reaching that stage on a newly deployed server takes serveral iterations
> of 'puppet agent'.

Before figuring out how to shorten the initial agent runs, I'd inquire why a full configuration takes several agent runs. It would be pretty easy to build a host where puppet runs as a daemon with runinterval=60, and when puppet configures the host it stops its daemon process and sets itself to run via cron, but that gets odd if it takes several agent runs to get the host going.

> Each client calls the puppet agent as a cron job, every 30 minutes. That's
> fine after machine is fully configured, but means that there's a long
> interval between kickstarting a new machine and having it reach a
> usable state.
>
> Essentially, I'd like the calls to 'puppet agent' to loop continuously
> (with a very short pause) until classes in the 'post' stage have met
> their requirements and executed once, at which time the server is fully
> configured and puppet can be run at the normal 30-minute interval.
>
> Any suggestions?

If you have some way of populating an "everything is done" file, you can have a custom fact read that file and report true/false. If true, puppet's cron job will be every 30 minutes, and if false, the cron job happens every minute.

http://docs.puppetlabs.com/facter/2.1/custom_facts.html

if str2bool($::donefact) {
$minute = '*'
}
else {
$minute = '30'
}

cron { 'puppet':
minute => $minute,
command => '/usr/sbin/puppet agent --onetime',

}

(Off the top of my head untested suggestion.)

> Thanks,
>
> Mark
>
> --
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/9989-1406566383.024520%40NNlb.KxuX.QQYv.
> For more options, visit https://groups.google.com/d/optout.

Christopher Wood

unread,
Jul 28, 2014, 3:25:00 PM7/28/14
to puppet...@googlegroups.com
On Mon, Jul 28, 2014 at 03:20:04PM -0400, Christopher Wood wrote:

(Hm, true/false reversed here. Test first!)

jcbollinger

unread,
Jul 29, 2014, 11:26:31 AM7/29/14
to puppet...@googlegroups.com


On Monday, July 28, 2014 2:20:33 PM UTC-5, Christopher Wood wrote:
Before figuring out how to shorten the initial agent runs, I'd inquire why a full configuration takes several agent runs.

+1

I have never seen or heard about an environment that required multiple Puppet runs to converge to a stable configuration.  I may have seen one or two where it was more convenient to allow two runs for convergence than to make the necessary arrangements for Puppet to apply a complete config to a new machine in just one run.  But never more than two, even for convenience.


John

Jason Antman

unread,
Jul 30, 2014, 8:31:38 AM7/30/14
to puppet...@googlegroups.com
I've seen those environments. I've worked in them. A few host types in my current environment are like that. IT IS A BUG. The only valid reason for this is either a bug in your manifests/modules, or that things aren't ordered properly.

That being said... don't run via cron. If you're using any sort of provisioning system, just have that run puppet until it succeeds. If you're not, then at host provisioning time, you could use a script that runs puppet until it succeeds.


--
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...@googlegroups.com.

jcbollinger

unread,
Jul 31, 2014, 9:21:50 AM7/31/14
to puppet...@googlegroups.com


On Wednesday, July 30, 2014 7:31:38 AM UTC-5, Jason Antman wrote:
I've seen those environments. I've worked in them. A few host types in my current environment are like that. IT IS A BUG. The only valid reason for this is either a bug in your manifests/modules, or that things aren't ordered properly.



You misunderstand me.  I can readily believe that some environments do take multiple Puppet runs to converge.  I'm saying that there is nothing in those environments that inherently prevents Puppet from syncing the whole system in just one run.  So, agreed, if systems take multiple Puppet runs to converge to a stable configuration then there is a bug in the manifest set, data, and/or ENC.

 
That being said... don't run via cron.


... if all you want it for is provisioning.  For Puppet's core use -- ongoing configuration management -- there are a lot of advantages to scheduling agent runs via cron instead of running the agent as a daemon.  Also a couple of limitations.


John

Jason Antman

unread,
Aug 13, 2014, 8:50:58 AM8/13/14
to puppet...@googlegroups.com



On Thu, Jul 31, 2014 at 9:21 AM, jcbollinger <John.Bo...@stjude.org> wrote:

 
That being said... don't run via cron.


... if all you want it for is provisioning.  For Puppet's core use -- ongoing configuration management -- there are a lot of advantages to scheduling agent runs via cron instead of running the agent as a daemon.  Also a couple of limitations.


John

Ever since I started running via MCollective, I think I was crazy to ever have done otherwise. Especially with `mco puppet runall N` where N is the number of concurrent nodes my master can support.

José Luis Ledesma

unread,
Aug 13, 2014, 8:56:50 AM8/13/14
to puppet...@googlegroups.com

+1000

--
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...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages