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 <joseluis.lede...@gmail.com> 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 puppet-users+unsubscr...@googlegroups.com. > 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAMo7R_eJT7vFx3veB0GWvUreZwNDgVohW_15ceer8wkEH1z9Tw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
