On Tue, 28 Mar 2006, David Lutterkort wrote:
The problem with (4) is that you mix describing what you want to be done
with how it is done, which has a number of disadvantages.
I agree, the biggest disadvantages with 4) IMO are:
1) Overhead of keeping the build scripts up to date
2) Determining what should be scripted vs done manually
3) Roll back / change revision is very difficult.
4) This approach can easily cause confusion on "objective" vs
"implementation" for a 3rd party.
It is my opinion that in an ideal world the OS/configuration engine would
be able to largely eliminate these disadvantages by tracking the history
of all configuration changes from inital system build to current state,
independent of how the change was made (scripted, distributed, manually at
the console, etc...). It seems to me this would be trivial if every
configuration element was easily identifiable by path (filesystem),
key name (filename) and it's value (content). Obviously there are
practical considerations that make this difficult, performance, number of
files, what should be a directory vs a file vs content etc...
I have been using another config mgmt system, puppet,
(http://reductivelabs.com/projects/puppet) I wrote up an example of how
a config mgmt tool could help in solving the kind of problem you are
looking at: http://people.redhat.com/dlutter/puppet-app.html
Puppet looks like a very promising centralized change distribution system.
As you mentioned this separates the "how" changes are applied from the
"what" is actually changing. If you combine the change re-visioning
concept mentioned above with a puppet like centralized distribution system
that can detect client changes we now have something quite impressive. In
fact it resembles very much what I have with my Cisco equipment +
management software.
A lighter-weight approach seems more promising: encapsulate most of the
config-file specific knowledge in simple script wrappers that can be
controlled by a declarative description of the configuration you want to
achieve and the logical interdependencies between them. This is what
puppet does, and why I find it very attractive.
I mostly agree, although very elegant compared to what exists today I
would still classify it as a work-around.
Cheers,
Shane
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
