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/52C2BD83.2050805%40jasonantman.com. For more options, visit https://groups.google.com/groups/opt_out.
