There is another option, mcollective. Using cron is somewhat manual, and you have to determine whenever to run puppet to avoid a thundering herd effect.
Mcollective lets you use the Mco puppet runall <concurrency> Where the concurrency sets how many agents run at the same time. It is resielent as cron is, and also you have a central point of puppet agents management, instead of (semi) manually set cron entries. Regards El 30/04/2014 17:21, "jcbollinger" <[email protected]> escribió: > > > On Tuesday, April 29, 2014 10:15:35 AM UTC-5, Christopher Wood wrote: >> >> >> Can't hosts already stagger their agent checkin times by using per-host >> runinterval settings? >> >> > > No. Different agents with different runintervals will still all hit the > server at nearly the same time when they are started together, and they > will do so again periodically thereafter (just not every run). Moreover, > it's nasty to use a policy knob such as runinterval to address a technical > issue such as avoiding a thundering herd effect. > > Puppet does have the 'splay' and 'splaylimit' configuration settings as a > possible solution, however. If you can accept some variation in the > interval between one agent run and the next then those are pretty > effective, albeit non-deterministic. > > > >> At some point, sure, agents may not be the best path forward but I don't >> see when I'd reach that point. >> >> > > I'm uncertain whether by "agents" you mean running the agent as a service, > or whether you mean using the agent at all (as opposed to using "puppet > apply"). Garrett was not suggesting the latter; he was suggesting using > cron to schedule runs of the agent in non-daemon mode. You can also > schedule runs of "puppet apply" that way, but that's a whole different ball > game. > > There is a lot to be said for scheduling the agent via cron. In addition > to possible applications in load leveling, it can make Puppet more > resilient. For example, I was recently working on the provider of a custom > type, and I managed to let a broken version escape to some of my systems, > where it crashed the agent daemon. I had to manually restart the daemons > on those systems. If I were launching Puppet from cron then the Puppet > runs would still have failed, but the next runs, when a fixed version of > the provider was available, would have gone fine without any manual > intervention. > > In addition, where Puppet manages its own configuration, launching it via > cron is much cleaner. Not necessary, as I understand it, but cleaner and > therefore less open to unexpected behavior. In the past, people have > launched Puppet that way also to avoid creeping memory usage, though I > think those memory problems are solved in any recent Puppet. > > On the other hand, the system service infrastructure is a bit more natural > and simpler to use than is cron. Nevertheless, for my own site I have > vague plans to switch from running Puppet as its own service to launching > it via cron, at some indefinite point in the future. > > > John > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/c0aa9f0c-7730-481e-b026-8ac80df43a5f%40googlegroups.com<https://groups.google.com/d/msgid/puppet-users/c0aa9f0c-7730-481e-b026-8ac80df43a5f%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAF_B3deYrqpYqn0sd5OHx-TeHRTWNv01gK--gNpvqC-Ff2W4OQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
