On Tue, 2006-04-18 at 16:03 -0700, David Lutterkort wrote: > On Tue, 2006-04-18 at 18:29 -0400, seth vidal wrote: > > What we did at duke was to take snippets of kickstarts and assemble them > > in whatever order per-profile using glump: > > http://linux.duke.edu/projects/mini/glump/ > > Cool .. if I understand that page right, glump is a combination of a > templating system and a config management system. > Yes, that's correct. It is very simple in how it puts files together. You use the xml to specify the components(members) of a result and you just use wget or what-have-you to grab the resulting concatenations of the files. > > It sounds like puppet is taking that a step further by allowing the > > conversation to go both ways. > > That, and very flexible mechanisms on how you associate specific > configurations with hosts; in addition, puppet models various aspects of > a system's configuration in its own declarative language, which nicely > decouples the 'what' of the desired system state from the 'how' of > achieving that state. One of puppet's goals is to make it possible to > describe a system's configuration in a modular way oriented along > logical lines. For example, it should be possible to describe the setup > of a webserver and a DB server (needed packages, config files, users, > mounts etc.) completely separately from each other and then combine > 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. 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. > > It's kind a shame puppet isn't in python - it would make it easier to > > integrate some of the pkg handling mechanisms of yum with it if it were. > > When you say "package { httpd: version => '2.0.54' }" or "package > { mysql-server: ensure => latest }" in your puppet manifest, puppet will > use yum to install/update those packages to the appropriate versions; so > far, that level of yum integration seems to be sufficient. I've also > writen a 'yumrepo' type that lets you express the yum configuration > within a puppet manifest - that should help in controlling what repos > each machine uses for package installs/updates. > 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. I was talking with the puppet lead on irc. It sounds like the flow is: puppet server takes manifests/recipes and compiles them into yaml yaml is sent to the client client reads yaml and does stuff with it 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. or better yet just have a web interface that dumps the selected items out to yaml (or, given the transforms, xml) then stores that into a db and dispenses with recipes altogether? -sv -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
