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? (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. 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? (3) Apache The ovirt-wui RPM already drops the right files into /etc/httpd/conf.d to make an ovirt virtual host. (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. (5) iSCSI server This is a bit of an unknown quantity. Can oVirt run without an iSCSI server? (6) collectd Should soon be added to Fedora, so not a problem. (7) Packages from Fedora: ruby, rails, kvm, libvirt, ntp, etc. These aren't really an issue because RPM can deal with installing them. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v
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 never saw them, so I can't help you there.> > (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.Right. That being said, it is just the "next-server" directive, which I think is a required part of the DHCP spec (that is, it is not some exotic DHCP option record anymore). However, for people who don't have control of their DHCP server, it could be an issue.> > 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?Eh. I'm guessing that for the initial target, if people are using real, physical machines as managed nodes, they'll either have a DHCP setup with PXE that works, have the ability to do so, or can use a USB key. I don't think we really need to mandate this.> > (3) Apache > > The ovirt-wui RPM already drops the right files into /etc/httpd/conf.d > to make an ovirt virtual host. > > (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.There are essentially 4 parts for setting up the database (all of which the appliance do at first-boot time): 1) service postgresql initdb 2) Run a series of postgresql commands to create the ovirt database user and create the ovirt database (this is in /usr/share/ovirt-wui/psql.cmds on the appliance) 3) cd /usr/share/ovirt-wui ; rake db:migrate (this actually creates the needed database tables) 4) /usr/share/ovirt-wui/scripts/grant_admin_privileges admin (this grants top-level admin privileges to the kerberos user "admin", so that he can then manage the other users/resources)> > (5) iSCSI server > > This is a bit of an unknown quantity. Can oVirt run without an iSCSI > server?Yes, the WUI can start without iSCSI. What iSCSI is really required for right now is for starting VMs on the managed nodes. Given the storage API's, it should be possible to use other things (like NFS, etc.); we just haven't coded it up yet.> > (6) collectd > > Should soon be added to Fedora, so not a problem. > > (7) Packages from Fedora: ruby, rails, kvm, libvirt, ntp, etc. > > These aren't really an issue because RPM can deal with installing > them.And don't forget the custom RPMs we currently have in the ovirt repository, notably updated libvirt with the storage patches + my custom iSCSI patch, updated KVM (from rawhide), updated kernel (from rawhide), updated livecd-tools (with rjones live-cd-to-pxe-script), custom ruby-libvirt bindings, and the custom ruby-kerberos bindings. Chris Lalancette
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 -=|