[et-mgmt-tools] Cobbler & inherited profiles

[Michael DeHaan]

I figured I would share a bit on what's been going on with upstream 
Cobbler lately.

As Euclid suggested on IRC a while back, I'm moving Cobbler to a 
"even=stable, odd=unstable" release convention.  This makes the current 
cobbler release 0.4.8 stable, and in a week or so, I'll push Cobbler 
0.5.0 out to F7-testing (but not FC6, as it has no "testing" yet).   
There will be RPMs, but no Fedora-7 or FC-6 push.  Not immediately, anyway.

Why split off a testing release?   Lots of new cool stuff coming in.  
The most notable feature is support for profile inheritance.   A lot of 
the ideas for this suggestion came in from Adam Rosenwald (thanks, Adam) 
-- I believe there were some earlier discussions about this too, sorry I 
forget who was involved.    Anyhow, this feature is illustrated as follows:

cobbler profile add --name=xyz --virt-ram=512 --virt-size=5 
--distro=distro_name --kickstart=/path
cobbler profile add --name=xyz2 --inherit=xyz --virt-size=6

In the above example, cobbler profile p2 is going to be the same as p1, 
even when p1 changes, except for an override in the --virt-size 
parameter.  
This can be seen by looking at the saved cobbler profile files, where 
you'll see a lot of parameters are stored as "<<inherit>>" which means, 
I don't have a setting, ask my parent.  And yes, there can be any number 
of levels of inheritance.

A further example:

cobbler import --path=/mnt/dvdiso --name=FC-6
cobbler profile add --name=FC-6-xen-i386-webserver 
--inherit=FC-6-xen-i386 --kickstart=/path/to/special/kickstart
cobbler profile add --name=FC-6-xen-i386-dbserver 
--inherit=FC-6-xen-i386 --kickstart=/path/to/another/kickstart
cobbler profile edit --name=FC-6-xen-i386 --virt-ram=6
cobbler profile add --name=FC-6-xen-i386-webserver-more-disk 
--inherit=FC-6-xen-i386-webserver --virt-disk=10
cobbler sync

In the above example, I've derived two profiles from the profile I get 
for free from the "cobbler import".   I have assigned different 
kickstarts to both of them.
Then, I go and edit their parent kickstart, and have, effectively, 
changed the --virt-ram value for both of them.   A quick way to see what 
actually happens to  the
"calculated" values of FC-6-xen-i386-webserver-moredisk is to look at 
the file in /var/www/cobbler/profiles/$name ... you'll see all the 
values -- and the cool thing is,
that in 0.5.0, every single one of these values is available in Cheetah 
templating -- which is fairly cool.

This inheritance blending also works for ks_meta (templating) variables 
and kernel options.  In those cases, you can add additional kernel 
options to existing options part of a parent profile, or you can 
override existing ones with new values.

cobbler profile add --name=p1 ...
cobbler profile add --name=p2 --inherit=p2 --ksmeta="moose=lodge"

The above example would use all of the templating metadata values of p1, 
but would set the additional value of "moose" to the value "lodge".

The implementation of the above is available now in git -- with only a 
bit of polishing still needed.   Namely, awareness of cascade updates so 
running sync on the entire
cobbler tree is not required after an edit to a parent node.

When is this useful?   The example Adam gave, and I think it's a good 
one, is if a site had multiple locations, with different policy rules 
between them, and one also wanted to have system roles (webserver, 
dbserver) underneath of each of these policies.   An inheritance system 
makes something like this possible.

Right now, only profiles are inheritable (not distros or systems), and 
it's only single inheritance.  No, you should never need an OOP textbook 
to understand Cobbler.  That would be wrong :)

Questions?  Comments?  Fire away.

(Note that Cobbler 0.5.0 also contains dnsmasq support (including DNS!), 
edit/copy/rename commands, and being able to name systems after things 
that aren't MAC addresses -- so, if you're interested in any of the 
above, check out the git repo)

Thanks!

--Michael