[Yum] groupreq and yum 2.6

David Lutterkort dlutter at redhat.com
Tue Apr 18 21:48:08 UTC 2006

On Tue, 2006-04-18 at 15:42 -0400, Brian Long wrote:
> The classes of machines are defined in profiles in make_bootdisk, a CGI
> that generates ks.cfg and PXE configuration (part of http://kickstart-
> tools.sf.net).  These profiles might be named for the class of machine
> like "Engineering Workstation" or the CGI might offer checkboxes of
> optional yum groups that can get installed if the end user would like.
> The CGI is configured such that Engineering Workstation installs certain
> yum groups but right now it's at a high level and we rarely change it.
> We typically change the yumgroups.xml file and re-gen the repos.  If I
> move the source of truth from yumgroups.xml to each profile, it's
> increases my maintenance cost.  For each profile that references a
> single nested yumgroup, I'd have to edit manually if I can no longer
> nest yumgroups.  For example, if the yumgroup "Engineering-Workstation"
> contains "Base-Workstation", "RealPlayer", "Xine", etc.  I'll have to
> list each of those subgroups in all the Engineering Workstation
> profiles.  Right now, if I need to make a change to all Engineering
> Workstations, I change the Engineering-Workstation yumgroup and regen
> the repos.

This is not directly connected to your question about yumgroups, but it
seems that you are using yumgroups very similar to how classes are
traditionally used in config management tools like cfengine. Instead of
using yumgroups to express similarities between machines, have you
thought about using a config management tool to express the desired
state of machines ? Depending on what exactly you need to do to
kickstart to a specific profile, this might also save you from building
config-only rpms.

I've been looking at puppet [1] quite a bit and have written a tutorial
on how it can be used to model the kind of layering you are doing with
yumgroups [2] We are also working on a simple tool to help distribute
and manage 'system recipes' based on puppet [3].

I would appreciate any feedback on these things, in particular the idea
of moving away from using rpm's as the _only_ means of expressing the
desired configuration of machines.


[1] http://reductivelabs.com/projects/puppet
[2] http://people.redhat.com/dlutter/puppet-app.html
[3] http://people.redhat.com/alikins/prm/prm.README

More information about the Yum mailing list