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

Reply via email to