qemu modularization of qemu-5.1 vs libvirt domcapabilities cache?

[Jim Fehlig]

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.

If we can agree on an approach I'd be happy to take a stab at implementing it.

Regards,
Jim