[et-mgmt-tools] Cobbler & inherited profiles
Adam Rosenwald
thestrider at gmail.com
Thu Jun 14 07:23:24 UTC 2007
Two questions:
Question: What count as inheritable attributes? Naturally, --name is
not inheritable. But what about --uuid or --disk-location (when these
are later moved from koan to cobbler :) )? --disk-location might be
unique on a given physical system X; i.e. once I provision virtual
system Y on physical system X with --disk-location=Z, Z cannot be used
as a disk location for any other virtual system on physical system X.
But when the context shifts to more than one physical system,
--disk-location can suddenly be an attribute worth inheriting, say, if
all web servers (implemented as virtual systems) hosted on all physical
systems use --disk-location=Z.
Question: What are "reasonable defaults"? For instance, in the case of
--vcpus, the default is currently set to "1" in koan. This isn't that
great of an example, as --vcpus is not currently customizable without
modifying koan code (BTW, an effort is being made to move virt
attributes from koan to cobbler profiles, to address this issue). In
some cases, perhaps the default attributes can be set to "DYNAMIC",
where information gathered from proc or sysfs can fill in the values
later on koan's end. In the --vcpus example, if the physical system
only has one physical CPU (no hyperthreading, additional cores for the
sake of argument), --vcpus should be one. If the physical system has
multiple CPUs, cores, and/or hyperthreading, the dynamically-generated
value can be computed on Koan's end. Disk size and RAM are other
potential candidates for dynamic default values.
The benefit of profile inheritance within the context of these questions
is enormous, as entire data center provisioning topologies can be gotten
from a simple "cobbler list". With profile inheritance, it may be
beneficial to change the cobbler list functionality (or at least to
provide an command-line argument) to provide a tree structure. This
could, in essence, show something like the following crude picture (P
being profiles without systems yet provisioned; S being systems):
Data Center
---------------
+
|
+-----------+subnet2+---------+functional group1+
|
/ \
|
/ \
|
+ +
|
P1 P2
+
subnet1+--------+functional group2+----------+
+ /|\
| / | \
| / | \
| / | \
| + + +
| S1 S2 S3
+
functional group3+-------+S4
...where each branch is a profile and each leaf is either a system or a
profile. As the number of profiles and systems grows, some
organizational tool like the above (although much better than the above
:) ) can help traverse the inheritance tree.
Just a thought,
- A.
---
Great work, BTW, Michael. :) Can't wait for 0.6!
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)
>
> Thanks!
>
> --Michael
>
>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>
More information about the et-mgmt-tools
mailing list