On Tue, 2006-04-18 at 19:39 -0400, seth vidal wrote:
> > these two descriptions on one machine to support webapp X. The
> > modularity requires that configurations are not just pushed around as
> > opaque files, but can be described as 'objects', i.e. allow the
> > administrator to talk about users, packages, mounts etc. rather
> > than /etc/passwd or /etc/fstab.
> >
>
> except that means that a lot of work has to go into the client side that
> ends up having to parse the result of the manifests/recipes from puppet.
> A LOT of work, in fact.
Most of the work for a specific config object is actually in
parsing/manipulating the appropriate config files on the client side,
not in parsing the puppet manifest.
> That's one thing we escaped with glump. Glump just creates the files
> programs on the client use. What those clients are or what the format of
> the file is, glump doesn't care.
That's certainly preferrable over parsing config files, but it's not
always feasible. For example, think of all the config files that are
really databases of various objects like passwd or fstab - managing
those on the file level is usually not granular enough, and you need to
manage them on the 'record' level.
> But performing conditionals like:
>
> if package { httpd: version >= '2.0.54'} then install package 'foo' is
> not all that simple and may not be all that possible, either.
Yeah .. does this come up in practice ? It seems that package 'foo' in
that scenario is doing something very strange.
> What I couldn't figure out is why I'd write how to do it in the recipes
> to begin with. Why not just write it in yaml and store that in a db
> per-host/per-class/per-profile and be done with it.
yaml/xml isn't very human readable. The puppet language also lets you
group things in a way that is easier to understand for humans (check out
'class' and 'define' in the language reference), both of which are
resolved on the server.
> or better yet just have a web interface that dumps the selected items
> out to yaml (or, given the transforms, xml)
Certainly something that would be desirable at some point in the future,
but writing a good UI is hard; and as far as the language is concerned,
the emphasis right now should be more on making it easy to model
configurations of a large number of systems. There are plenty of things
that could be added to the language to make that easier.
And as a side-effect, the puppet language makes it easy to distribute
parts of a system's configuration as a 'recipe', a canned HOWTO, while
leaving users of the recipes some leeway in modifying them locally and
later incorporating updates from upstream without clobbering local
modifications. That would be much harder in a strictly DB-based system.
David
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
