Re: [et-mgmt-tools] Cobbler & inherited profiles

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Adam Rosenwald wrote:
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.

Currently everything except --name is inheritable. Items that hold hash data merge, arrays concatenate, and scalars override. Disk location? Here's how I would do it. Have a parameter in the cobbler profile called --default-disk-location. This would default to the value koan uses today (koan, if using different values, has to pay attention to SELinux contexts). This would be a path on the filesystem, for example a SAN mount point. koan would, if this path exists and is writable, would use that for image creation, instead of the current path in /var/lib/xen. LVM locations don't really make sense to be migrated around in Cobbler (as cobbler does not -- and shouldn't -- maintain storage inventory of host storage layout), could be specified by using a parameter in koan to override the storage configuration. If koan is invoked with --lvm=partition (or equivalent) it would install the disk image there instead, though migration capability would be sacrificed. Picking a free partition by default wouldn't be sane, but --lvm=auto could potentially contain special automatic to try, allowing koan to be used to install guests using LVM partitions from within kickstart %post sections for the dom0 (host). I can see that being useful.

I am not sure why you would want explicit UUID control. Can you give an example?


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.
Disagree. One of the purposes of virtualization is the creation of a predictable and repeatable environment -- hardware isolation. If a cobbler profile defines a particular profile, that profile should dictate the requirements of the installation. Having them change based on the host would be a bit hard to predict, and we also do not know how many virtual guests are going to be installed on a given host. It is true that this information can be scaled after the fact, so rebalancing is possible. However, at install time, koan doesn't know what else you want to do with the rest of the box, and we don't want to suck up all the free RAM and that might be needed to install more virtual guests.

Ideally koan would have command line options to override or supplement any specifications in a cobbler profile for installations in those environments.

Don't get me wrong though -- these are good suggestions. They are perhaps much apt to apply to where we're going with Virt-Factory (http://virt-factory.et.redhat.com) than Cobbler though -- one of our longer term goals for that is to be able to define a cloud of virtual systems and have the management software make suggestions about where to deploy virtual machines and how to migrate/scale resources intelligently. Hard problem, but a very fun problem just the same :) To get there though, we have to assemble a bit more supporting infrastructure in that project first.

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):
It kind of already does that, though not entirely how you suggest...

"cobbler list"

It looks something like...

distro $name
   profile $name
      profile $name
        system $name
   profile $name
        system $name



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.

Three words:  "cobbler generate graphviz"  :)

And, as much as I like charts and graphs, I'll probably have to do it :)

--Michael


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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools


_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools


[Index of Archives]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux