[et-mgmt-tools] Cobbler & inherited profiles
thestrider at gmail.com
Thu Jun 14 07:32:39 UTC 2007
I should have known better than to draw a diagram on a mailing list. :)
Please imagine what that /might/ have looked like if it made any sense. :)
Michael DeHaan wrote:
> 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)
> et-mgmt-tools mailing list
> et-mgmt-tools at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the et-mgmt-tools