A default deployment on modern distros uses modular daemons but switching back to the monolithic daemon, while not recommended, is still considered a perfectly valid option. For a monolithic daemon deployment, the upgrade to libvirt 9.2.0 or newer works as expected; a subsequent call to dnf autoremove, however, results in the libvirt-daemon package being removed and the deployment no longer working. In order to avoid that situation, mark the libvirt-daemon as recommended. This will unfortunately result in it being included in most installations despite not being necessary, but considering that the alternative is breaking existing setups on upgrade it feels like a reasonable tradeoff. Moreover, since the dependency on libvirt-daemon is just a weak one, it's still possible for people looking to minimize the footprint of their installation to manually remove the package after installation, mitigating the drawbacks of this approach.

On Wed, Aug 30, 2023 at 07:25:23PM +0200, Erik Skultety wrote: > On Wed, Aug 30, 2023 at 06:22:33PM +0200, Andrea Bolognani wrote: > > A default deployment on modern distros uses modular daemons but > > switching back to the monolithic daemon, while not recommended, > > is still considered a perfectly valid option. > > > > For a monolithic daemon deployment, the upgrade to libvirt 9.2.0 > > or newer works as expected; a subsequent call to dnf autoremove, > > however, results in the libvirt-daemon package being removed and > > the deployment no longer working. > > > > In order to avoid that situation, mark the libvirt-daemon as > > recommended. > > > > This will unfortunately result in it being included in most > > installations despite not being necessary, but considering that > > the alternative is breaking existing setups on upgrade it feels > > like a reasonable tradeoff. > > > > Moreover, since the dependency on libvirt-daemon is just a weak > > one, it's still possible for people looking to minimize the > > footprint of their installation to manually remove the package > > after installation, mitigating the drawbacks of this approach. > > Not just that, experienced users can even skip installation of it with using > '--setopt=install_weak_deps=False'. Yeah, but that tells dnf to skip *all* weak dependencies, so for example you won't get passt either, which you might have wanted. apt is better in this regard, because while you can use $ apt-get install --no-install-recommends libvirt-daemon-kvm to skip all weak dependencies, same as dnf, you can also use $ apt-get install libvirt-daemon-kvm libvirt-daemon- (note the trailing -) to install all other weak dependencies but skip libvirt-daemon specifically. > Footprint aside, I don't see a practical > problem having both installed even if unused since it allows users switching > between the deployment modes seamlessly without having to go and install an > extra package. Having both available means that it's easier for people to end up with messed up deployments. For example, some automation that was written before modular daemons were introduced might unconditionally enable libvirtd. If libvirtd is present on the machine, that will result in both modular and monolithic daemons being enabled; if it isn't, you will get an error message and an opportunity to improve the automation so that it's aware of modular daemons. That said, this has been the status quo for the last few years, when it was simply not possible to get rid of libvirtd, so this patch at least doesn't make things any worse :) > FWIW: > Reviewed-by: Erik Skultety <eskultet(a)redhat.com&gt; Thanks. Daniel, Jirka, do you have any objections or can I go ahead and merge?

On Thu, Aug 31, 2023 at 09:50:07AM +0100, Daniel P. Berrangé wrote: > On Thu, Aug 31, 2023 at 01:43:44AM -0700, Andrea Bolognani wrote: > > On Wed, Aug 30, 2023 at 07:25:23PM +0200, Erik Skultety wrote: > > > On Wed, Aug 30, 2023 at 06:22:33PM +0200, Andrea Bolognani wrote: > > > > A default deployment on modern distros uses modular daemons but > > > > switching back to the monolithic daemon, while not recommended, > > > > is still considered a perfectly valid option. > > > > > > > > For a monolithic daemon deployment, the upgrade to libvirt 9.2.0 > > > > or newer works as expected; a subsequent call to dnf autoremove, > > > > however, results in the libvirt-daemon package being removed and > > > > the deployment no longer working. > > > > > > > > In order to avoid that situation, mark the libvirt-daemon as > > > > recommended. > > > > > > > > This will unfortunately result in it being included in most > > > > installations despite not being necessary, but considering that > > > > the alternative is breaking existing setups on upgrade it feels > > > > like a reasonable tradeoff. > > > > > > > > Moreover, since the dependency on libvirt-daemon is just a weak > > > > one, it's still possible for people looking to minimize the > > > > footprint of their installation to manually remove the package > > > > after installation, mitigating the drawbacks of this approach. > > > > > > Not just that, experienced users can even skip installation of it with using > > > '--setopt=install_weak_deps=False'. > > > > Yeah, but that tells dnf to skip *all* weak dependencies, so for > > example you won't get passt either, which you might have wanted. > > > > apt is better in this regard, because while you can use > > > > $ apt-get install --no-install-recommends libvirt-daemon-kvm > > > > to skip all weak dependencies, same as dnf, you can also use > > > > $ apt-get install libvirt-daemon-kvm libvirt-daemon- > > > > (note the trailing -) to install all other weak dependencies but skip > > libvirt-daemon specifically. > > > > > Footprint aside, I don't see a practical > > > problem having both installed even if unused since it allows users switching > > > between the deployment modes seamlessly without having to go and install an > > > extra package. > > > > Having both available means that it's easier for people to end up > > with messed up deployments. > > > > For example, some automation that was written before modular daemons > > were introduced might unconditionally enable libvirtd. If libvirtd is > > present on the machine, that will result in both modular and > > monolithic daemons being enabled; if it isn't, you will get an error > > message and an opportunity to improve the automation so that it's > > aware of modular daemons. > > > > That said, this has been the status quo for the last few years, when > > it was simply not possible to get rid of libvirtd, so this patch at > > least doesn't make things any worse :) > > > > > FWIW: > > > Reviewed-by: Erik Skultety <eskultet(a)redhat.com&gt; > > > > Thanks. > > > > Daniel, Jirka, do you have any objections or can I go ahead and > > merge? > > 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. This is IMO a problem that ought to be solved by thorough documentation as something that despite best effort can't be eliminated easily in a transparent manner and an easy fix is in place (enable/disable the right services).

> I'm not seeing a good way to deal with the upgrade problem though. > I could possibly make the argument that Fedora has defaulted to > modular daemons for new installs for long enough that we should > assume all installs are running modular. Still, we have a proof > by counter-example that such an assumption is not entirely true. > > I guess your proposal here is still better than the historical > practice though, because even if it gets installd by default, > we can at least now erase it if desired. > > 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. > > And then eventually we can delete it entirely upstream. Why though? Monolithic daemon still plays an important role in development deployments where this setup is much much easier to debug than in the modular daemons setup.

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.