[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On Tue, Apr 03, 2012 at 02:08:11PM +0100, Daniel P. Berrange wrote:
> 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.

  okay ...

> > 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.

  good !

> > >  - 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.

  I still wonder if it is worth it then. Adding an extra empty rpm just
for the sake or avoiding a explicit hypervisor dependency at the
application level. The whole scheme adds N + 1 empty rpms just for
avoiding that dep that the application need to explicitely state right
now anyway.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel veillard com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]