Something like "/etc/init.d/tomcat stop", "deploy", "/etc/init.d/tomcat start". It also would be great to manage services in general. Like stop/start/restart service X.
On Wed, Feb 10, 2010 at 8:49 PM, Michael DeHaan <mich...@reductivelabs.com> wrote: > Daniel wrote: >> >> Sounds promising. What about a combination of shell execution and a >> normal puppetrun? Something like run a shell command, apply catalog, >> run another command. >> >> > > Possibly --- What's the shell command in that example so I can grok the use > case? > > OT -- one thing I didn't explain about Func is it had the notion of "do this > N at a time", in our particular case, > there may be an opportunity to teach N hosts to update at a time, and then > do N hosts later... so in very large > setups, it would be possible to do easy rolling puppetmaster updates. > Func actually handled this by forking and running synchronously, so this > would need to be a bit different. > > --Michael > > >> On Wed, Feb 10, 2010 at 6:45 PM, 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. >>> 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. > > -- Cheers, Daniel -- 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.
