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