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.
