questions regarding modular daemons

[Jim Fehlig]

On 9/30/22 02:01, Daniel P. Berrangé wrote:
> On Thu, Sep 29, 2022 at 04:22:50PM -0600, Jim Fehlig wrote:
>> Hi All,
>>
>> I've procrastinated long enough and finally decided to switch to modular
>> daemons in openSUSE Factory libvirt package. For the most part, the Factory
>> spec file mimics the upstream one. I enabled with_modular_daemons and would
>> like to confirm the results of my testing.
>>
>> When upgrading an existing installation running the monolithic daemon, the
>> monolithic daemon is still enabled after the upgrade. I suppose this
>> behavior is expected, and fine IMO.
> 
> Yes, thus far we decided not to try seemlessly swapping existing
> installs over to the modular daemons. While this doesn't affect
> libvirt API, it does affects various aspects of system configuration,
> so there's a risk of breaking cfg mgmt tool scripts for ansible/puppet/etc
> 
>> However, when installing the "modularized" packages on a system with no
>> prior installation, the monolithic daemon is still installed and potentially
>> enabled in posttrans. Having both the monolithic and modular daemons
>> installed, along with all associated systemd socket and service files, is a
>> bit confusing to users IMO. E.g. should one enable libvirtd sockets,
>> virtqemud sockets, both?
> 
> In Fedora we use systemd defaults to control which gets enabled in
> new installs:
> 
>    https://src.fedoraproject.org/rpms/fedora-release/blob/rawhide/f/90-default.preset#_65
> 
> these defaults match that are set in RPM post scripts. So libvirtd
> is present, and so is its unit file, but they're not enabled. A
> strong solution would be to use systemctl mask to force block
> libvirtd too.
> 
>> Is the intention, over time, to remove the monolithic daemon? Perhaps we
>> could start by isolating the monolithic daemon in the libvirt-daemon
>> subpackage and moving the other daemons (virtproxyd, virtlogd, virtlockd,
>> etc) to a new subpackage? The modular daemons could then drop the
>> libvirt-daemon dependency, allowing installation without the monolithic
>> daemon.
> 
> Yeah, long term the idea is to remove libvirtd, but there's no timeframe
> for that because I've been trying to ignore the in-place upgrade problems.
> 
> Ideally it would be possible to install the module daemons, without
> also pulling in libvirtd, but the upstream libvirt.spec.in doesn't
> allow for that yet.

I finally got around to sending an initial series that decomposes the daemon 
subpackage

https://listman.redhat.com/archives/libvir-list/2022-November/235924.html

Regards,
Jim