[Ovirt-devel] ovirt dependencies

[Daniel P. Berrange]

On Thu, Feb 28, 2008 at 06:31:28PM +0000, Richard W.M. Jones wrote:
> I'm trying to build a definitive list of 'external' dependencies for
> oVirt.  By 'external' I mean dependencies on non-Fedora packages,
> network services, anything which needs a difficult or unusual
> configuration.
> 
> The underlying question here is what would it take to be able to
> simply 'yum install ovirt-wui' to create a WUI?
> 
> Please follow-up if I've missed any.
> 
> (1a) FreeIPA server
> (1b) Kerberos support in the browser
>
> Does someone have Scott Seago's patches for "null" authentication?

I don't believe he finished it before he went away.

> (2) DHCP, PXE, TFTP
> 
> At the moment we provide some very complex instructions for setting up
> dhcpd & TFTP.
> 
> DHCP is used for two things: (a) to pass the name of the PXE server to
> a booting node and (b) to pass a single configuration option to the
> managed node.  As Dan suggested, (b) could be done with zeroconf.
> (a) seems like it will always require configuration.

The configuration options we can definitely get rid of. The WUI could
broadcast them with zeroconf, allthough that might increase the boot
time of the managed nodes while they wait for a broadcast info. Would
have to look at Avahi in detail to check if that's a problem or not.

> PXE, TFTP is used to boot the managed nodes.
> 
> Can we run a self-contained dnsmasq (similar to the dnsmasq
> configuration used by libvirt) to do all of this work?  Yes, in as
> much as dnsmasq works for me to PXEboot the managed host.
> 
> Maybe we should mandate that in the "minimal" configuration people
> should always boot managed hosts using a USB key?

That's is certainly doable. PXE is most appropriate is large networks
where you don't have physical access. For small / developer networks
using a LiveCD, or Live USB key is clearly a good option, particularly
if we move config out of DHCP and into zeroconf.

With this the only remaining requirement for DHCP would be the ability to
set fixed DNS mappings, required to make Kerberos work nicely.

> (3) Apache
> 
> The ovirt-wui RPM already drops the right files into /etc/httpd/conf.d
> to make an ovirt virtual host.

Yep. Just need some config magic to FreeIPA to make it play nicely with
other application

> (4) PostgreSQL
> 
> Setting up databases is always hard: Should we create the database?
> What happens if the database already exists?  (Upgrades are hard to do
> and error-prone).  But leaving a SQL file around and asking the user
> to load it by hand seems reasonable enough.
> 
> I notice that the current ovirt-wui RPM leaves a script around to
> create the database but my ruby isn't good enough to tell how the full
> database schema is created.

Really a few steps:

  - InitDB  - Fedora initscripts take care of this already
  - Create user - su - postgres and add the user account 
  - Create DB - again a manual step
  - Config auth - twiddle pg_hba.conf
  - Import schema - Ruby provides a convenient command for this IIRC

The first 4 are pretty much common to any DB app and really a documentation
exercise. We can provide a script to help loading of the schema.

> (5) iSCSI server
> 
> This is a bit of an unknown quantity.  Can oVirt run without an iSCSI
> server?

Not right now, but it will be able to.

Once we use the storage APIs, then we have the generic API to manage any
storage. THe next logical step for oVirt is to support LVM to carve up
LUNs. Once do you are doing that, carving up local internal disks is much
the same. And ading SAN / FibreChannel is not far behind. Its mostly a
UI question, rather than a technology question at this point. If you don't 
care about migration, then simply use the local internal disk for dev 
purposes. If you do need migration, then we can support NFS with the storage
APIs.



So I think we have a good story for dealing with most of these issues. The
only one which may remain 'hard' long term will be Kerberos. Hopefully the
FreeIPA guys will make deployment easier.

It is a shame we can't leverage libvirt's other auth schemes though, since
that allows TLS/x509 certs, and even  plain username+password auth. Supporting
this though has implications for policy management / group management, since
we had intended to push this all off to FreeIPA too.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|