Re: questions regarding modular daemons

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