Adrian Likins wrote:
I'm kind of a fan of the idea of modules supporting some common
utility methods if applicable. The best
examples of this currently are the .inventory() and .info() methods.
I was thinking another good case would be a .backup() and .restore()
methods. With the idea being that
the results of .backup() could be stored, and restored with a call to
the .restore() method. Simple idea,
but I think it could useful, especially with the recent improvements
in the async behavior making potentially
long running commands a bit more useful.
existing modules that seem like good candidates would include iptables
(which more or less already has
this cability), sysctl, services (aka, store chkconfig state), and
maybe filetracker.
I think in most cases, .backup() and .inventory() are different uses,
though some cases it can surely
be the same (sysctl for example, is probably basically the same). But
with the main idea that .backup()
would include enough info to restore from "scantily clad metal"[1] state.
If it works somewhat like func-inventory (automatically backing up
everything that can be backed up remotely) that may be intersting.
There's one problem though. If you are deploying any /new/ systems,
you really don't want there to be a difference between deploying config
files and "restoring" them in most cases. So you do want something
declarative. I can see wanting to make a backup of all of your
hetereogenous
systems though, and then selectively restoring stuff, but best practices
for a large configuration, I'd rather have something that told the machine
what it was supposed to be.
This is the kind of scenario where you would want something like Puppet
or the (not yet written) "Remote Rocket Surgery" app for Func.
Another idea to deal with this is to teach Func's copyfile about how to
do some very shiny templating, and be able to push config files
out centrally, using perhaps the module-specific config file idea or
even storing the template info on the overlord. This too, could grow a
bit unwieldy.
I'd say we can do the backup thing, especially if it's doing /remote/
backups (we are talking about that right?) but I'm not sure it's
sustainable for
large deployments. One case it /could/ be useful though, is it fetched
a bunch of remote config files, allowed you to edit the "backups" and then
push them back out, keeping them under version control. This way you
could do centrally managed config files for lots of boxes.
Anyhow, I think Func is about choice as opposed to enforcing any
particular workflow, so we really can do all of the above, but putting some
"Best Practices" kind of info on the Wiki might not be a bad idea.
--Michael
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
