[libvirt] [PATCH 00/10] Enable loadable modules for libvirtd

[Daniel P. Berrange]

On Tue, Apr 03, 2012 at 05:41:57PM +0800, Daniel Veillard wrote:
> On Tue, Apr 03, 2012 at 10:06:02AM +0100, Daniel P. Berrange wrote:
> > On Tue, Apr 03, 2012 at 04:22:59PM +0800, Daniel Veillard wrote:

> >  - libvirt-daemon - Just the libvirtd daemon, no drivers, no configs
> >  - libvirt-daemon-config-network  - Just the virbr0 configs
> 
>  let's rename to libvirt-daemon-bridge then !

No, I explicitly chose to have -config' in the name, because this
really is just the config files, and we might want to use the
name 'libvirt-daemon-bridge' at some point in the future.

> >  - libvirt-daemon-config-nwfilter - Just the firewall configs
> 
>  and libvirt-daemon-nwfilter

Again, I want config there to ensure that the libvirt-ademon-nwfilter
RPM name is availble for future use.

> the fact that the rpm contains config files, or .so, or binaries the
> user should care only of what functionality is provided.

The actual nwfilter functionality is provided in the libvirt-daemon
RPM, so to suggest they need to use libvirt-daemon-nwfilter is
misleading - this is only some default config files which apps
do not need to use if they don't want them - oVirt uses its own
configs for example.

> If we split it that much then we must make sure that
>    rpm -i libvirt-daemon-nwfilter
> will actually restart the server in the %post (and true for most of the
> others package, may turn into a challenge when installing 4 extension
> package and we want to avoid restarting the server 4 times !)

In the re-post I did, I use  %posttrans script to ensure it is restarted
once, at the end of the transaction.

> >  - libvirt-daemon-driver-XXX   - Contains the dlopen'd modules per driver
> >                                  or sub-driver. One for each XXX in: (uml,
> >                                  qemu, xen, lxc, storage, network, nwfilter,
> >                                  interface, nodedev, secrets)
> 
>   this is what I dislike, I would prefer to see
> libvirt-kvm and libvirt-daemon-driver-kvm to be merged (and hence
> my question about qemu and kvm because the .so would be shared I assume)
> unless there is a good story for having only the .so in the rpm
> that's the part I really reacted to when I made my tentative build for
> the release and that looks way to intricate to my taste.

It is not possible to merge these to. For backwards compatibility,
we need 'libvirt' to depend on 'libvirt-daemon-driver-qemu'. We
do *not*, however, want 'libvirt' to pull in 'qemu' itself.

It becomes clear when you consider what the entry points for
application dependancies are:

  /---> libvirt --------+---------> libvirt-daemon
  |                     |                  ^
  |                     |                  |
  |                     \---------> libvirt-daemon-driver-qemu
  |                                     |  |
  +---> libvirt-daemon-qemu ------------+--|------> qemu
  |                                        |
  +---> libvirt-daemon-kvm ----------------+------> qemu-kvm
  |
 App Choice

So 'yum install libvirt', does *not* pull in 'qemu', 'qemu-kvm' or 'xen'


If we merged the packages as you describe, we'd end up with


  /---> libvirt --------+---------> libvirt-daemon
  |                     |                  ^
  |                     \-------------\    |
  |                            |      |    |
  |                            |      V    |
  |----------------------------|--> libvirt-daemon-driver-qemu ---> qemu
  |                            |
  |                            \------\
  |                                   |
  |                                   V
  |-------------------------------> libvirt-daemon-driver-qemu ---> qemu-kvm
  |
App Choice


So, 'yum install libvirt' would end up pulling in every single hypervisor
we support (qemu, qemu-kvm, xen), which is not at all what we want.

Separating the libvirt-daemon-XXX packages from the libvirt-daemon-driver-XXX
packages is key to achieving the goal of minimising install footprint, while
maintaining backwards compatibility with existing RPM deps.

Rgards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|