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