[Ovirt-devel] Re: ovirt integration w/ cobbler

[Michael DeHaan]

Daniel P. Berrange wrote:
> On Tue, Feb 12, 2008 at 11:55:29AM -0500, Michael DeHaan wrote:
>   
>> It doesn't do ISOs yet, but that's something that could be added.
>>
>> It would require some minor cobbler/koan changes.   If someone is 
>> interested in working with me on that, that's great...
>> if not, if I can better understand the requirements it should not be 
>> that complex to add myself.
>>
>> Basically I'm guessing you want to either do:
>> (a)  fullvirt provisioning where there is no PXE server, and you can't 
>> do kernel+initrd installs like koan does now (like Xen FV works on F8)
>> (b)  non-Linux installs (make koan deploy an arbitrary OS)
>>     
>
> Yep, we've got 2 core use cases:
>
>  - Deploying the 'managed host' images. This is a pre-built minimal
>    Fedora image essentially onl running libvirt. The idea being you
>    turn on a physical host, it PXE's this image and joins itself to
>    the oVirt management server and can now have guests deployed on it
>    We can build images such that they have a kernel+initrd if needed.
>   
Neat!
>  - Deploying the guest OS'.  This can be any OS, be it Linux, Windows
>    BSD, Solaris, etc. Obviously Fedora / RHEL are trivial since we
>    can always do kernel+initrd from the main distro trees.
>
>   
>> One thing that might also be interesting for ovirt is the koan live CD 
>> ... basically it allows you to insert a CD/USB-image into any baremetal 
>> machine,
>> boot it, and it will install to whatever cobbler profile you want... 
>> this can be either a preset profile, e.g. "foo", or can be detected 
>> based on the MAC
>> address.   This could be any distro as well, so a F8/F9 based installer 
>> image could install EL4.   Kinda neat if you need to add new machines
>> to your "cloud" and ovirt isn't the "official" provisioning server.
>>     
>
> That sounds like a nice idea for places where we can't directly use PXE.
>
>   
>> The APIs are pretty solid at this point -- Virt-Factory was using them, 
>> Cobbler's web UI is using them now, and I can add anything that isn't there.
>> Auth is also pluggable now so we can write a module to use whatever 
>> authentication system ovirt might be using.
>>     
>
> Are there any docs on the APIs available for controlling Cobbler ?
>   

https://fedorahosted.org/cobbler/wiki/CobblerXmlrpc

see also remote.py in the source tree for exposed methods plus the WebUI 
source for further examples.
(the Cobbler WebUI isn't that complicated -- basically just one python 
file -- ./cobbler/webui/CobblerWeb.py)

Virt-Factory just used cobbler's Python API directly -- which is a bit 
cleaner than going the XMLRPC
route -- though the XMLRPC API is not too bad either.

> For authentication we're basically Kerberos enabled throughout. All the
> services and users have kerberos tickets / principals. If the Cobbler
> APIs can be setup to go via Apache's  mod_kerb that should do the trick
> quite nicely. At worse we can copy the FreeIPA approach of having Apache
> do the auth and then proxypass the request through to Cobbler which can
> read the authenticated username from the HTTP request.
>   

Cobbler's authn system is pluggable, so technically you can swap out the 
default digest file implementation
for something else (/etc/cobbler/modules.conf).

The existing kerberos stuff (off by default) in there for Cobbler is not 
very good or finished (definitely
it's "fake kerberos"), so it would probably need to be redone. By 
default we use the Apache auth handlers to just
send the username/password back down to cobblerd, where it is checked 
there (communicating with cobblerd) to return pass/fail.

The FreeIPA style hack you mention with mod_kerb may work.... I'll look 
into how (if?) we can get at those headers from Python's XMLRPC
server.