Kickstart and roles

[David Lutterkort]

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.

> 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. 

> 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.

David