Ovirt devel - Jul 2008 - Details about pending cobbler image support & ovirt integration

Hi folks,

So I'm still working on the image tracking support for Cobbler ... I've 
been a bit sidetracked with other Cobbler/Func items though this is the 
/big/ item for Cobbler 1.1.   Anyhow, I wanted to provide a basic 
summary of what will be going on there in Cobbler land to make sure 
we're all on the same page, and that ovirt can get what it wants out of 
this.   I should also add that I am more than happy to take patches if 
you'd like to work on Cobbler directly :)

Essentially the idea is that cobbler contains a series of related 
objects.... Distros, Profiles, Systems, and Repos at the base level.   
In ovirt's case, we do not care so much about repos.

A distro record contains info about a kernel, initrd, and tree -- and 
maybe some additional kernel options and so forth.

A profile takes a distro and adds a kickstart, and specific parameters 
that (if providing a virtual install environment) pass extra parameters 
to python-virtinst when invoked with koan.

A system takes a profile and customizes it further -- for instance, it 
may add networking info or specific kickstart or kernel options 
customizations.

Images are the new object.   We want cobbler to track them like other 
objects.

    # cobbler image add --name=QuestionableRemondInstallISO 
--file=/mnt/nfs/blah/foo.img

Then we are going to teach koan about images.   Currently koan can be 
used to reinstall existing systems or launch VM installations, but it 
doesn't know about images.

This will look like:

   # koan --server=cobbler.example.org 
--image=QuestionableRemondInstallISO --virt

And that will kick of the install using the centrally managed parameters.

The next thing to do after getting fullvirt ISO tracking done is to make 
sure --file can just take NFS urls and mount them (I'll look into the 
libvirt storage stuff for this).

After that, we also teach "cobbler image add" to track images that can
be fed to virt-image, AKA virt disk images.   This will have a similar 
syntax, most likely...

# cobbler image add --name=MysteryOS --file=/mnt/nfs/blah/foo.img 
--image-type=blah [--virt-ram=] [--virt-disk=] [etc]

The --virt parameters will work basically as they do with cobbler 
profiles today.

All of the cobbler image stuff will also be accessible over the web service.

So most likely ovirt would have to make the calls to add new images (and 
their details) into the "registry" (via cobbler XMLRPC) and then on
the
host end, make the right calls to koan to replicate them on demand.

The next logical step after handling virt-images is perhaps teaching 
cobbler about physical images and cloning tools, though I'm much more 
interested in the virt case, as I have no problem if all the hypervisors 
out there have to run Linux :)

The other thing we might want to talk about are cobbler triggers, which 
could be written to notify ovirt of changes to the cobbler configuration 
-- this is similar to something we are planning with Spacewalk.   In 
general, I think ovirt would mostly be giving orders to cobbler, but if 
someone makes a change outside of cobbler, like deleting a virt-image 
ovirt wants to have used, it should probably have a way of knowing it 
should re-scan cobbler XMLRPC to see what changed.

Kerberos authorization can be configured here ... 
https://fedorahosted.org/cobbler/wiki/CobblerWithKerberos though I 
should mention I found a way to get cobbler to authenticate against 
Spacewalk here... 
https://www.redhat.com/archives/spacewalk-devel/2008-July/msg00024.html 
-- in that general theme, it would be possible to write a cobbler auth 
plugin that allowed Cobbler to defer authorization of it's own API into 
ovirt if we really wanted to.   That probably won't be neccessary 
though, but I thought I'd throw it out there.

The other thing I'd like to see is Cobbler managing /tftpboot for ovirt 
and PXE for ovirt, which I think was something you wanted to do.   All 
of those APIs are stable now -- if someone wants pointers on how all 
that works just let me know.

Thanks!

--Michael

On Wed, 2008-07-09 at 09:28 -0400, Michael DeHaan wrote:
> Images are the new object.   We want cobbler to track them like other 
> objects.
> 
>     # cobbler image add --name=QuestionableRemondInstallISO 
> --file=/mnt/nfs/blah/foo.img
Are images also meant for bare-metal installs or only for VM installs ?
> After that, we also teach "cobbler image add" to track images
that can
> be fed to virt-image, AKA virt disk images.   This will have a similar 
> syntax, most likely...
> 
> # cobbler image add --name=MysteryOS --file=/mnt/nfs/blah/foo.img 
> --image-type=blah [--virt-ram=] [--virt-disk=] [etc]
> 
> The --virt parameters will work basically as they do with cobbler 
> profiles today.
It would be much simpler for VM images to tell cobbler to add an
image.xml; all the parameters above are listed in that, and adding a VM
image to a cobbler server would be as simple as
        
        # cobbler image add /foo/bar/image.xml
        
and koan would basically take the same command line args as virt-image;
the only thing on top of what virt-image does is that koan would have to
make the actual disk files available on the local host.

There's one small wrinkle: when you instantiate from an image, you can
treat that image either as an immutable template (in which case you'd
have to copy the disk files) or as the image for a specific VM (in which
case you'd directly use the disk files to back the VM)
> The next logical step after handling virt-images is perhaps teaching 
> cobbler about physical images and cloning tools, though I'm much more 
> interested in the virt case, as I have no problem if all the hypervisors 
> out there have to run Linux :)
Heh .. yeah, definitely the more interesting first step.
> The other thing we might want to talk about are cobbler triggers, which 
> could be written to notify ovirt of changes to the cobbler configuration 
> -- this is similar to something we are planning with Spacewalk.   In 
> general, I think ovirt would mostly be giving orders to cobbler, but if 
> someone makes a change outside of cobbler, like deleting a virt-image 
> ovirt wants to have used, it should probably have a way of knowing it 
> should re-scan cobbler XMLRPC to see what changed.
Yeah, might definitely be useful; though very very soon we'll all be
talking amqp, and ovirt can just pick notifications off the bus, right ?

David