qemu modularization of qemu-5.1 vs libvirt domcapabilities cache?

[Daniel P. Berrangé]

On Thu, Aug 20, 2020 at 09:05:56AM -0600, Jim Fehlig wrote:
> On 8/20/20 8:56 AM, Jim Fehlig wrote:
> > On 8/20/20 6:54 AM, Christian Ehrhardt wrote:
> > > On Thu, Aug 20, 2020 at 12:43 PM Martin Wilck <mwilck at suse.com> wrote:
> > > > 
> > > > On Thu, 2020-08-20 at 11:00 +0100, Daniel P. Berrangé wrote:
> > > > > On Wed, Aug 05, 2020 at 10:19:26AM +0200, Andrea Bolognani wrote:
> > > > > > contents change.
> > > > > > 
> > > > > > That said, if upgrading QEMU results in losing features, even
> > > > > > though
> > > > > > you can recover them through additional steps I would argue that's
> > > > > > a
> > > > > > bug in the packaging that should be addressed on the QEMU side.
> > > > > 
> > > > > Potentially we can consider this a  distro packaging problem and fix
> > > > > it at the RPM level.
> > > > > 
> > > > > eg the libvirt RPM can define a trigger that runs when *any* of the
> > > > > qemu-device*  RPMs is installed/updated. This trigger can simply
> > > > > touch a file on disk somewhere, and libvirtd can monitor this one
> > > > > file, instead of having to monitor every module.
> > > > 
> > > > The simplest approach is to touch the qemu binaries. We discussed this
> > > > already. It has the drawback that it makes "rpm -V" complain about
> > > > wrong timestamps. It might also confuse backup software. Still, it
> > > > might be a viable short-term workaround if nothing else is available.
> > > 
> > > Qemu already allows to save modules in /var/run/qemu/ [1] to better handle
> > > module upgrades which is already used in Debian and Ubuntu to avoid
> > > late module load errors after upgrades.
> > > 
> > > This was meant for upgrades, but if libvirt would define a known path in
> > > there like /var/run/qemu/last_packaging_change the packages could easily
> > > touch it on any install/remove/update as Daniel suggested and libvirt could
> > > check this path like it does with the date of the qemu binary already.
> > 
> > That would require changes in libvirt and the various module packages
> > right? Are you fine with Daniel's suggestion of handling this all within
> > libvirt? E.g. on the packaging side libvirt could define a trigger to be
> > notified when the modules dir is updated and touch a well-known file
> > 
> > %filetriggerin -- %{_libdir}/qemu
> > touch /var/cache/libvirt/qemu/capabilities/module-changed
> > %filetriggerun -- %{_libdir}/qemu
> > touch /var/cache/libvirt/qemu/capabilities/module-changed
> 
> Hmm, this is still problematic for session mode. I think your suggestion
> covers both system and session modes nicely.

Hmm, yeah, session mode ought not to be looking at the
/var/cache directory tree ideally, as we like to keep
the daemons fully isolated.

I wonder if we really do just need to traverse the module
directory. readdir+stat'ing 10-20 files is still waaaay
faster than not having any caching at all.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|