The current implementation pretty much assumes that targets
where modular daemons are the default will stick with that
configuration, as will targets where they're not, or that
changes to these defaults will be performed by the admin after
the packages have been installed.

This is unnecessarily limiting: for example, on a target that
defaults to using the monolithic daemon, it's entirely possible
to create a local preset such as

  # /etc/systemd/system-preset/00-virt.preset
  disable libvirtd.service
  disable libvirtd*.socket
  enable virtqemud.service

to opt into a modular daemon deployment. The opposite is of
course also true. We shouldn't get in the way of these
reasonable use cases.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
---
 libvirt.spec.in | 24 ------------------------
 1 file changed, 24 deletions(-)

diff --git a/libvirt.spec.in b/libvirt.spec.in
index db8d9158ae..c9317ed0cc 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -1487,9 +1487,7 @@ fi \
 %libvirt_sysconfig_pre libvirtd
 
 %post daemon
-%if ! %{with_modular_daemons}
 %libvirt_daemon_systemd_post_inet libvirtd
-%endif
 %libvirt_daemon_schedule_restart libvirtd
 
 %posttrans daemon
@@ -1591,9 +1589,7 @@ fi
 %libvirt_sysconfig_pre virtproxyd
 
 %post daemon-proxy
-%if %{with_modular_daemons}
 %libvirt_daemon_systemd_post_inet virtproxyd
-%endif
 
 %posttrans daemon-proxy
 %libvirt_sysconfig_posttrans virtproxyd
@@ -1609,9 +1605,7 @@ fi
     %firewalld_reload
 %endif
 
-%if %{with_modular_daemons}
 %libvirt_daemon_systemd_post virtnetworkd
-%endif
 %libvirt_daemon_schedule_restart virtnetworkd
 
 %posttrans daemon-driver-network
@@ -1630,9 +1624,7 @@ fi
 %libvirt_sysconfig_pre virtnwfilterd
 
 %post daemon-driver-nwfilter
-%if %{with_modular_daemons}
 %libvirt_daemon_systemd_post virtnwfilterd
-%endif
 %libvirt_daemon_schedule_restart virtnwfilterd
 
 %posttrans daemon-driver-nwfilter
@@ -1646,9 +1638,7 @@ fi
 %libvirt_sysconfig_pre virtnodedevd
 
 %post daemon-driver-nodedev
-%if %{with_modular_daemons}
 %libvirt_daemon_systemd_post virtnodedevd
-%endif
 %libvirt_daemon_schedule_restart virtnodedevd
 
 %posttrans daemon-driver-nodedev
@@ -1662,9 +1652,7 @@ fi
 %libvirt_sysconfig_pre virtinterfaced
 
 %post daemon-driver-interface
-%if %{with_modular_daemons}
 %libvirt_daemon_systemd_post virtinterfaced
-%endif
 %libvirt_daemon_schedule_restart virtinterfaced
 
 %posttrans daemon-driver-interface
@@ -1678,9 +1666,7 @@ fi
 %libvirt_sysconfig_pre virtsecretd
 
 %post daemon-driver-secret
-%if %{with_modular_daemons}
 %libvirt_daemon_systemd_post virtsecretd
-%endif
 %libvirt_daemon_schedule_restart virtsecretd
 
 %posttrans daemon-driver-secret
@@ -1694,9 +1680,7 @@ fi
 %libvirt_sysconfig_pre virtstoraged
 
 %post daemon-driver-storage-core
-%if %{with_modular_daemons}
 %libvirt_daemon_systemd_post virtstoraged
-%endif
 %libvirt_daemon_schedule_restart virtstoraged
 
 %posttrans daemon-driver-storage-core
@@ -1724,9 +1708,7 @@ fi
 exit 0
 
 %post daemon-driver-qemu
-    %if %{with_modular_daemons}
 %libvirt_daemon_systemd_post virtqemud
-    %endif
 %libvirt_daemon_schedule_restart virtqemud
 
 %posttrans daemon-driver-qemu
@@ -1742,9 +1724,7 @@ exit 0
 %libvirt_sysconfig_pre virtlxcd
 
 %post daemon-driver-lxc
-    %if %{with_modular_daemons}
 %libvirt_daemon_systemd_post virtlxcd
-    %endif
 %libvirt_daemon_schedule_restart virtlxcd
 
 %posttrans daemon-driver-lxc
@@ -1760,9 +1740,7 @@ exit 0
 %libvirt_sysconfig_pre virtvboxd
 
 %post daemon-driver-vbox
-    %if %{with_modular_daemons}
 %libvirt_daemon_systemd_post virtvboxd
-    %endif
 %libvirt_daemon_schedule_restart virtvboxd
 
 %posttrans daemon-driver-vbox
@@ -1778,9 +1756,7 @@ exit 0
 %libvirt_sysconfig_pre virtxend
 
 %post daemon-driver-libxl
-    %if %{with_modular_daemons}
 %libvirt_daemon_systemd_post virtxend
-    %endif
 %libvirt_daemon_schedule_restart virtxend
 
 %posttrans daemon-driver-libxl
-- 
2.41.0

On Fri, Jul 14, 2023 at 04:39:38PM +0200, Andrea Bolognani wrote:
>The current implementation pretty much assumes that targets
>where modular daemons are the default will stick with that
>configuration, as will targets where they're not, or that
>changes to these defaults will be performed by the admin after
>the packages have been installed.
>
>This is unnecessarily limiting: for example, on a target that
>defaults to using the monolithic daemon, it's entirely possible
>to create a local preset such as
>
>  # /etc/systemd/system-preset/00-virt.preset
>  disable libvirtd.service
>  disable libvirtd*.socket
>  enable virtqemud.service
>
>to opt into a modular daemon deployment. The opposite is of
>course also true. We shouldn't get in the way of these
>reasonable use cases.
>
>Signed-off-by: Andrea Bolognani <abologna@redhat.com>

I could thought only of one thing that could be a problem, tracked it
down and then found out it will not be an issue.  So I think this is
fine.

Reviewed-by: Martin Kletzander <mkletzan@redhat.com>

On Mon, Jul 24, 2023 at 04:36:07PM +0200, Martin Kletzander wrote:
> On Fri, Jul 14, 2023 at 04:39:38PM +0200, Andrea Bolognani wrote:
> > The current implementation pretty much assumes that targets
> > where modular daemons are the default will stick with that
> > configuration, as will targets where they're not, or that
> > changes to these defaults will be performed by the admin after
> > the packages have been installed.
> >
> > This is unnecessarily limiting: for example, on a target that
> > defaults to using the monolithic daemon, it's entirely possible
> > to create a local preset such as
> >
> >  # /etc/systemd/system-preset/00-virt.preset
> >  disable libvirtd.service
> >  disable libvirtd*.socket
> >  enable virtqemud.service
> >
> > to opt into a modular daemon deployment. The opposite is of
> > course also true. We shouldn't get in the way of these
> > reasonable use cases.
>
> I could thought only of one thing that could be a problem, tracked it
> down and then found out it will not be an issue.  So I think this is
> fine.

Out of curiosity, what scenario did you have in mind?

To be honest I've only verified that this works correctly with my new
macros, which at this point of the series are not yet used. I'm
fairly confident the same applies even to the standard macros, but
I'll check that too for completeness' sake.

-- 
Andrea Bolognani / Red Hat / Virtualization

On Tue, Jul 25, 2023 at 10:55:54AM -0400, Andrea Bolognani wrote:
>On Mon, Jul 24, 2023 at 04:36:07PM +0200, Martin Kletzander wrote:
>> On Fri, Jul 14, 2023 at 04:39:38PM +0200, Andrea Bolognani wrote:
>> > The current implementation pretty much assumes that targets
>> > where modular daemons are the default will stick with that
>> > configuration, as will targets where they're not, or that
>> > changes to these defaults will be performed by the admin after
>> > the packages have been installed.
>> >
>> > This is unnecessarily limiting: for example, on a target that
>> > defaults to using the monolithic daemon, it's entirely possible
>> > to create a local preset such as
>> >
>> >  # /etc/systemd/system-preset/00-virt.preset
>> >  disable libvirtd.service
>> >  disable libvirtd*.socket
>> >  enable virtqemud.service
>> >
>> > to opt into a modular daemon deployment. The opposite is of
>> > course also true. We shouldn't get in the way of these
>> > reasonable use cases.
>>
>> I could thought only of one thing that could be a problem, tracked it
>> down and then found out it will not be an issue.  So I think this is
>> fine.
>
>Out of curiosity, what scenario did you have in mind?
>

One thing that makes different sense to me every time I read it is the
way the presets override themselves.  The wording from
systemd.preset(5) is a bit confusing sometimes, but I read it again and
properly and found out everything is fine.  Don't worry about it =)

>To be honest I've only verified that this works correctly with my new
>macros, which at this point of the series are not yet used. I'm
>fairly confident the same applies even to the standard macros, but
>I'll check that too for completeness' sake.
>

It'd be nice to get some real-life testing, but issue that this is
trying to fix is not going to manifest in rolling distros any more
anyway, that one we need to test for, but we know how.  If there's more
we'll see it in the distros for which this is actually fixing the
existing issue(s).

>--
>Andrea Bolognani / Red Hat / Virtualization
>