[libvirt PATCH] rpm: Recommend libvirt-daemon for with_modular_daemons distros
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. https://bugzilla.redhat.com/show_bug.cgi?id=2232805 Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- libvirt.spec.in | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/libvirt.spec.in b/libvirt.spec.in index 6bbc7a0e9a..b471afebb1 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -830,6 +830,7 @@ Requires: libvirt-daemon-log = %{version}-%{release} Requires: libvirt-daemon-lock = %{version}-%{release} Requires: libvirt-daemon-plugin-lockd = %{version}-%{release} Requires: libvirt-daemon-proxy = %{version}-%{release} +Recommends: libvirt-daemon = %{version}-%{release} %else Requires: libvirt-daemon = %{version}-%{release} %endif @@ -857,6 +858,7 @@ Requires: libvirt-daemon-log = %{version}-%{release} Requires: libvirt-daemon-lock = %{version}-%{release} Requires: libvirt-daemon-plugin-lockd = %{version}-%{release} Requires: libvirt-daemon-proxy = %{version}-%{release} +Recommends: libvirt-daemon = %{version}-%{release} %else Requires: libvirt-daemon = %{version}-%{release} %endif @@ -881,6 +883,7 @@ Summary: Server side daemon & driver required to run LXC guests %if %{with_modular_daemons} Requires: libvirt-daemon-common = %{version}-%{release} Requires: libvirt-daemon-proxy = %{version}-%{release} +Recommends: libvirt-daemon = %{version}-%{release} %else Requires: libvirt-daemon = %{version}-%{release} %endif @@ -906,6 +909,7 @@ Requires: libvirt-daemon-common = %{version}-%{release} Requires: libvirt-daemon-lock = %{version}-%{release} Requires: libvirt-daemon-plugin-lockd = %{version}-%{release} Requires: libvirt-daemon-proxy = %{version}-%{release} +Recommends: libvirt-daemon = %{version}-%{release} %else Requires: libvirt-daemon = %{version}-%{release} %endif @@ -930,6 +934,7 @@ Summary: Server side daemon & driver required to run VirtualBox guests %if %{with_modular_daemons} Requires: libvirt-daemon-common = %{version}-%{release} Requires: libvirt-daemon-proxy = %{version}-%{release} +Recommends: libvirt-daemon = %{version}-%{release} %else Requires: libvirt-daemon = %{version}-%{release} %endif -- 2.41.0
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'. 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. FWIW: Reviewed-by: Erik Skultety <eskultet@redhat.com>
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@redhat.com>
Thanks. Daniel, Jirka, do you have any objections or can I go ahead and merge? -- Andrea Bolognani / Red Hat / Virtualization
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@redhat.com>
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. 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. With regards, Daniel [1] still want a build opt-in for a while for any (probably enterprise0 distros that want to keep it around longer for compatibility reasons -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
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@redhat.com>
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. Erik
On Thu, Aug 31, 2023 at 11:00:27AM +0200, Erik Skultety wrote:
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@redhat.com>
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).
The volume of bugs I see which involve confusion between modular and monolithic daemon is large enough that I don't think docs are a viable solution. The confusion will remain as long as both exist in the installation IMHO.
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.
Personally I find the modular daemon easier to debug with, because when you turn up logs you're not distracted by logs from one of the other drivers (especially node device daemon is very chatty) and distracting. Again the rationale for deleting it entirely is to reduce confusion by eliminating the redundant choice. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
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
On Thu, Aug 31, 2023 at 02:14:49AM -0700, Andrea Bolognani wrote:
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.
Isnt %postinst too late in the upgrade process for this to work ?
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.
Yep, we'll have to bite the bullet eventually and make a decision, but for now lets keep our heads in the sand a bit longer :-) Meanwhile to be explicit about your current patch Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Thu, Aug 31, 2023 at 10:29:23AM +0100, Daniel P. Berrangé wrote:
On Thu, Aug 31, 2023 at 02:14:49AM -0700, Andrea Bolognani wrote:
On Thu, Aug 31, 2023 at 09:50:07AM +0100, Daniel P. Berrangé wrote:
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.
Isnt %postinst too late in the upgrade process for this to work ?
I haven't actually tested this approach, but I think it should be fine. The libvirt-daemon package gets updated as expected during upgrade, it's just that *after* the upgrade it's considered an obsolete dependency and thus candidate for autoremoval. So if you run $ dnf update && dnf autoremove the attempt to remove libvirt-daemon will only occur when the second command is executed, by which point %postinst will have already run.
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.
Yep, we'll have to bite the bullet eventually and make a decision, but for now lets keep our heads in the sand a bit longer :-)
Meanwhile to be explicit about your current patch
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Thanks, I'll push it then. -- Andrea Bolognani / Red Hat / Virtualization
participants (3)
-
Andrea Bolognani -
Daniel P. Berrangé -
Erik Skultety