On Thu, Aug 31, 2023 at 09:50:07AM +0100, Daniel P. Berrangé wrote:
> I don't much like it to be honest, as I was hoping we would get away
> from having it exist in any new installs, such that people were not
> mis-directed into trying to use it.
>
> I'm not seeing a good way to deal with the upgrade problem though.
Yeah. The two alternatives that I was able to come up with are
1) documenting in the release notes for Fedora and RHEL that
people using the monolithic daemon need to run
$ dnf mark install libvirt-daemon
before performing the upgrade;
2) in libvirt-daemon's %postinst, detect whether libvirtd is
enabled and if so run the command above.
I don't like 1) because it's really easy to miss something like that,
and if we're being honest most people don't even read the release
notes before performing an upgrade. The expectation is that things
will just work without user intervention, and I don't think it's an
unreasonable one.
2) would work but it feels so hacky that I didn't really consider
proposing it as an actual patch.
> Possibly the next step would be to stop building libvirtd by
> default in upstream releases[1], and figure out a way to attempt
> to auto switch installs to modular daemons during upgrade.
We have purposefully avoided converting monolithic deployments to
modular ones so far, but if we want to ever be able to drop the
monolithic daemon I'm afraid that at some point we'll have to take
the plunge. The alternatives are breaking all monolithic deployments
or carrying it around forever.
--
Andrea Bolognani / Red Hat / Virtualization
