[et-mgmt-tools] Cobbler query

[Michael DeHaan]

Chris Sarginson wrote:
> Hi Guys,
>
> I'm looking for a quick definitive answer regarding the cobbler system 
> add command:
>
> Basically I will be installing VM's, and they are frequently going to 
> have different RAM/disk size etc, so rather than creating an *insane* 
> amount of profiles for each distro + each possible virt config, I was 
> wondering if I could specify it on a system by system basis?
>
> Has anyone else tried/required this?
>
> I'm currently running on Fedora 7, and am just using yum provided 
> cobbler/koan.
>
>
The idea is that a profile should represent what the system does and 
is... the kickstart file, the RAM requirements, the disk requirements, 
and so forth -- to keep all of those things together to make a 
configuration like "virtual-webserver" completely reproducible and 
consistant.     In the end, that might even make there be less to 
configure, as you wouldn't need to create the per-system records.  An 
example of this is a development or test environment -- that profile 
might be rolled out an arbitrary number of times, and you wouldn't 
neccessarily want to require a cobbler record for every instance of that 
environment.  You'd just use koan with "--virt" and 
"--profile=development-environ".  Now, in an environment where you need 
DHCP reservations, then yes, you'd want the per-system records.   

How many profiles is insane, by the way?  :)  One thing that we have in 
Cobbler that is intended to help make this more manageable are the 
concept of inherited profiles.

The idea is that you could do:
    cobbler profile add  --name=webserver-base ....  --distro=blah
    cobbler profile add --name=webserver-base-moreram --virt-ram=1024 
--inherit=webserver-base

So, if you want to modify the profile "webserver-base" it would make 
changes to all of the subprofiles for you.   That may help.

koan does offer some local overrides, --virt-name, --virt-disk, 
--virt-bridge ... though we try to keep those minimal since it's 
supposed to be a central management way
of doing things.    Those are there for those folks who want to take 
advantage of a cobbler server outside of their normal working 
environment -- for instance, a standalone
box outside of a datacenter needs to install a cobbler profile, but the 
default image location does not suit the environment, etc.

Anyhow, let me know if the inherited profiles might work for you ... if 
not, we can think about whether per-system overrides of everything in 
the profile object
is a good idea or not.   I'm willing to remove those restrictions if 
enough folks find them valuable, though I still think profiles (and 
sub-profiles) are a very meaningful
abstraction.   For Web UI uses, we may even leave those overrides under 
an "advanced" tab or something of the like, to still encourage creation 
of task-specific
profiles.

Thoughts?

--Michael