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. David [1] http://reductivelabs.com/projects/puppet [2] http://people.redhat.com/dlutter/puppet-app.html [3] http://people.redhat.com/alikins/prm/prm.README
