Christian - we don't use puppet just to "make changes", we use it as (IMO) it was intended - to prevent divergence. We want it running every 30 minutes to make sure things stay how the manifests/modules say.
Jose - I think that may be the way I go, but I'm going to see if I can get something (perhaps RIP's puppetcommander, or something like it) to evenly balance the nodes. Thanks, Jason On 12/31/2013 09:32 AM, Cristian Falcas wrote: > Hi, > > At my work place we have puppet stopped completely. We only run it via > mco when we update the manifests. But this implies that you don't use > exported resources. > > regards, > Cristian Falcas > > On Tue, Dec 31, 2013 at 3:32 PM, Jose Luis Ledesma > <[email protected]> wrote: >> Hello, >> >> We have puppet only in the lab's servers, we are planning to deploy to >> production in the near future. I found myself thinking about the same >> question some time ago. >> >> What we were thinking is, why to run puppet agent on every node? In fact >> puppetlabs says about setting the puppet agent in the crontab... What we >> have done in the laboratory is to disable puppet agent, and run it always >> from the puppetmaster/mco-client crontab in the next way: >> >> 0 * * * * /usr/bin/mco puppet runonce --noop --splaylimit 900 >> >> >> I don't know if it's the best solution for productive-environment, >> opinions? >> >> regards, >> >> >> El martes, 31 de diciembre de 2013 13:50:11 UTC+1, Jason Antman escribió: >>> I also forgot the scariest option, which seems apt to break things: >>> - have mcollective stop the daemon >>> - mco puppet runonce >>> - have mcollective start the daemon back up >>> >>> -jason >>> >>> On 12/31/2013 07:42 AM, Jason Antman wrote: >>>> Hello, >>>> >>>> I've recently learned that my plans to use the puppet agent mcollective >>>> plugin to trigger one-time runs against a different environment, with >>>> the daemon running in the background, don't work because of how the >>>> agent plugin works (SIGUSR1 to the daemon if running). >>>> >>>> My original intent was as follows: >>>> I have a bunch of puppet nodes dedicated to testing new >>>> manifests/modules. Normally they, like all of my other nodes, run in >>>> daemon mode against the production environment. I have a Jenkins job >>>> that does some static testing of a specific branch of our puppet repo, >>>> and then checks out that branch as an environment on the master and >>>> (should/tries to) run `mco puppet runonce --environment <branchname>`. >>>> >>>> So, while I think the "runonce" name is pretty misleading if it can't >>>> handle running when there's a daemon, I understand the limitations >>>> behind it. Now I'm looking for any suggestions on how to achieve what >>>> I'm trying to. I've been able to come up with a few options... if anyone >>>> has other suggestions, or opinions, please pass them along... >>>> >>>> 1) https://tickets.puppetlabs.com/browse/PUP-1319 (formerly redmine >>>> 5153) "Ability to run --onetime in the background while a daemon is >>>> idle" implies that running "--onetime --no-deamonize --foreground" works >>>> fine while there's a backgrounded daemon. So all that would be needed is >>>> a change to the mco puppet plugin to explicitly add an option to allow >>>> this? I manually run "puppet agent -t --environment foo" all the time >>>> while the daemon is running, and it works fine. >>>> >>>> 2) As suggested by chris spence, I could stop using daemon mode and >>>> start using cron to trigger periodic runs. I've been running in daemon >>>> mode for a loooong time, but I guess with the deprecation of `puppet >>>> kick`, it's no longer needed. The remaining issue is how to spread out >>>> runs of all my nodes to minimize load on the master, and how to run at >>>> boot, which are solvable problems though more complex than "service >>>> puppet enable true". Any suggestions for how to spread out the runs? I'm >>>> using a custom ENC, so I suppose I could do it there as a param for >>>> cron, but I'm open to nicer solutions. >>>> >>>> 3) Going by R. I.'s blog post from 2010 (yeah a bit dated) >>>> >>>> http://www.devco.net/archives/2010/03/17/scheduling_puppet_with_mcollective.php >>>> about puppetcommander.rb, I could use something mco-based to schedule >>>> the runs. Though AFAIK this means running *that* controller either via >>>> cron on the master, or as a daemon somewhere (I assume the former would >>>> be preferable and easier). >>>> >>>> Any thoughts/suggestions? >>>> >>>> My main concerns are: >>>> 1) running 300+ nodes every 30 minutes, with load on the master >>>> distributed as evenly as possible. >>>> 2) Jenkins being able to force a given node or list of nodes to run >>>> immediately against an arbitrary environment. >>>> >>>> Thanks for any suggestions/feedback, >>>> J Antman >>>> >> -- >> 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/cebb4ac0-7e75-416b-bbed-3cacdbcc9542%40googlegroups.com. >> >> For more options, visit https://groups.google.com/groups/opt_out. -- 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/52C2F1E7.5020705%40jasonantman.com. For more options, visit https://groups.google.com/groups/opt_out.
