Hi, May I recommend that you have a look at the ext directory for puppetlisten/puppetrun[1], this two scripts I wrote a while ago reuse puppet certificate infrastructure to trigger remote runs.
additionally, I've created a query interface in foreman[2], which could probably give you some ideas of how integration can be done. by combining this two solutions, I think that you will have a very powerful solution. one thing to keep in mind is that many puppet users are using it via cron, because of the high memory footprint. thanks, Ohad *1 http://github.com/ohadlevy/puppet/tree/puppetlisten/ext/puppetlisten/ *2 http://theforeman.org/wiki/foreman/Query_Interface On Thu, Feb 11, 2010 at 1:45 AM, Michael DeHaan <mich...@reductivelabs.com>wrote: > Teyo, Bruce, and I were bouncing around some ideas resently for an > simple but enhanced puppetrun. > > Basically the idea is merging the ideas behind Func and Puppetrun. > Obviously other tools like mcollective have various other advantaged > features so this will be fairly primative by comparison, though it > won't require a message bus. If you want something more advanced > obviously try out those tools, this is covering a much smaller use case. > > This is something I am going to take a crack at this in the coming > weeks. This would be something pretty simple and lightweight, and > could > probably fix a lot of the use cases around making puppetrun (or > staggering large sets of hosts) a lot easier. > > Features I'm thinking of: > > Requires no additonal ports, setup, or config files -- use existing > puppet listening capability and puppetca, just a /usr/bin app > Be able to query dashboard DB to run against tagged nodes or hosts > that have certain data there (or in storeconfigs???) > Be able to run against wildcarded nodes based on what certs are > present on the puppetmaster (we know the hostnames) > Be able to be used easily from an API perspective from any ruby application > Be able to invoke ralsh remotely for querying things (and for debug, > and one off tasks) > Be able to run shell commands for things that are one offs (emergency > security power down now) > > Example syntax: > > punc --hosts *.example.org --puppetize # get new catalog and run > punc --hosts *.example.org --ralsh "service name=foo ensure=running" > # perform an action through ralsh > punc --hosts *.example.org --shell "/bin/emergency_script" # run a > shell script... for the one-off cases > punc --hosts foo.*.example.org --ralsh "service name=foo" > --format=json # query something with ralsh and generate a report > punc --hosts foo.*.example.org --facter fact --format=json # similarly > generate a facter report > punc --tags webservers [...ditto...] > punc --critiera "fact==foo" [..ditto...] > punc --critiera "fact==foo" [some operation to run only if fact > matches] [...ditto...] > > So for example we could choose to reboot all the servers that match a > given fact, etc. > > It should also allow easier staged deployments and environment usage > from apps that want to use the API. > > Additional ideas for stuff you would like to see? > > --Michael > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com<puppet-users%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
