On Tue, 2006-03-28 at 21:29 -0500, sean wrote:
> On Tue, 28 Mar 2006 17:51:14 -0800
> David Lutterkort <dlutter@xxxxxxxxxx> wrote:
>
> > While I agree in theory, the reality of config files with different
> > formats makes it extremely hard to get there. One approach that is being
> > pushed by a number of players to achieve uniform management of configs
> > is CIM/WBEM, an enormous standard that IMHO too much tool-specific
> > knowledge to see wide adoption.
> >
> > 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.
>
> Okay, so your script wrappers do all the config-file specific work etc.
> We talked about making a tool earlier in this conversation that would
> know how to handle all the different config file formats, so i'm with
> you up to there.
The pain of parsing different config file formats is only part of the
problem: the bigger problem are the semantics of all the config entries,
which the user still needs to understand.
> But what is the advantage of building an entire new config language
> around these wrappers? Couldn't they be manipulated just as easily
> with shell or python?
There are lots of advantages of a domain specific language over doing
this with basic scripts:
* It's easy to provide infrastructure for common tasks (like
logging or notification if changes are detected)
* The user expresses what they want to achieve rather than how to
achieve it
* The description represents the config in metadata and can be
processed by other tools. For comparison: since kickstart has a
well-defined file format, it's possible to write UI tools to
manipulate them, which wouldn't be possible if a kickstart file
was a shell script with some supporting utility scripts
* Some things that are hairy to express in scripts can be clearly
expressed in the language, e.g., dependencies between components
(put a custom httpd.conf into place before starting httpd; when
httpd.conf changes, httpd needs to be restarted) and logical
grouping of components for reuse (this is what I mean when I say
'webserver' or 'mailserver')
> Can the administrator make simple ad-hoc command line config file changes?
If you allow ad-hoc changes, you allow systems to deviate from the
predefined configuration; that may or may not be what you want. If it is
what you want, you should use the config mgmt tool only for the initial
setup, and then do your changes as you always would, without using the
tool. But if you are interested in keeping the config of several
machines in sync, you are better off making the changes in the config
mgmt tool's description.
David
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
