[libvirt PATCH 0/8] rpm: Fix handling of systemd units

Plus some extras I'm throwing in for free :) To understand why these changes are needed, see the original bug report[1] as well as the discussion triggered by Martin's initial attempt at addressing it[2]. Getting this right is quite tricky, so in order to convince myself that I'm not just going to break everyone's deployment I've tested things fairly extensively. In particular, I've verified that things work as expected when upgrading from libvirt 9.0.0 (e.g. pre-split) on AlmaLinux 8 when the initial configuration is * a default one (socket-activated monolithic daemon); * monolithic daemon with --listen; * modular daemons; * modular daemons with virtproxyd-tcp.socket enabled; as well as when installing from scratch with * no particular configuration; * local systemd preset overrides that result in the modular daemons being preferred to the monolithic one. Everything seems to work fine, but further testing would certainly be more than welcome! [1] https://bugzilla.redhat.com/show_bug.cgi?id=2210058 [2] https://listman.redhat.com/archives/libvir-list/2023-June/240226.html Andrea Bolognani (8): rpm: Bump min_fedora rpm: Style/alignment tweaks rpm: Reorder scriptlets rpm: Reduce use of with_modular_daemons rpm: Remove custom libvirtd restart logic rpm: Introduce new macros for handling of systemd units rpm: Switch to new macros for handling of systemd units rpm: Delete unused macros libvirt.spec.in | 453 +++++++++++++++++++++++++----------------------- 1 file changed, 232 insertions(+), 221 deletions(-) -- 2.41.0

According to our platform support policy, now that Fedora 38 is out we no longer target Fedora 36 and older. This allows us to simplify a few conditionals. Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- libvirt.spec.in | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 1f77cd90b7..c72b420e85 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -4,7 +4,7 @@ # that's still supported by the vendor. It may work on other distros # or versions, but no effort will be made to ensure that going forward. %define min_rhel 8 -%define min_fedora 33 +%define min_fedora 37 %define arches_qemu_kvm %{ix86} x86_64 %{power64} %{arm} aarch64 s390x %if 0%{?rhel} @@ -21,7 +21,7 @@ %define arches_systemtap_64bit %{arches_64bit} %define arches_dmidecode %{arches_x86} %define arches_xen %{arches_x86} aarch64 -%if 0%{?fedora} >= 36 +%if 0%{?fedora} %define arches_xen x86_64 aarch64 %endif %define arches_vbox %{arches_x86} @@ -134,7 +134,7 @@ %define with_firewalld_zone 0%{!?_without_firewalld_zone:1} -%if (0%{?fedora} && 0%{?fedora} < 34) || (0%{?rhel} && 0%{?rhel} < 9) +%if 0%{?rhel} && 0%{?rhel} < 9 %define with_netcf 0%{!?_without_netcf:1} %endif @@ -179,7 +179,7 @@ %endif %define with_modular_daemons 0 -%if 0%{?fedora} >= 35 || 0%{?rhel} >= 9 +%if 0%{?fedora} || 0%{?rhel} >= 9 %define with_modular_daemons 1 %endif @@ -347,7 +347,7 @@ BuildRequires: libssh2-devel >= 1.3.0 %if %{with_netcf} BuildRequires: netcf-devel >= 0.2.2 %endif -%if (0%{?fedora} >= 36) || (0%{?rhel} >= 9) +%if 0%{?fedora} || 0%{?rhel} >= 9 BuildRequires: passt %endif %if %{with_esx} @@ -467,7 +467,7 @@ Requires: dbus # For uid creation during pre Requires(pre): shadow-utils # Needed by /usr/libexec/libvirt-guests.sh script. -%if 0%{?fedora} >= 37 +%if 0%{?fedora} Requires: gettext-runtime %else Requires: gettext @@ -763,7 +763,7 @@ Requires: swtpm-tools %if %{with_numad} Requires: numad %endif - %if (0%{?fedora} >= 36) || (0%{?rhel} >= 9) + %if 0%{?fedora} || 0%{?rhel} >= 9 Recommends: passt Recommends: passt-selinux %endif -- 2.41.0

On Fri, Jul 14, 2023 at 04:39:35PM +0200, Andrea Bolognani wrote:
According to our platform support policy, now that Fedora 38 is out we no longer target Fedora 36 and older. This allows us to simplify a few conditionals.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>

Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- libvirt.spec.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index c72b420e85..05e322492a 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -22,7 +22,7 @@ %define arches_dmidecode %{arches_x86} %define arches_xen %{arches_x86} aarch64 %if 0%{?fedora} - %define arches_xen x86_64 aarch64 + %define arches_xen x86_64 aarch64 %endif %define arches_vbox %{arches_x86} %define arches_ceph %{arches_64bit} @@ -686,7 +686,7 @@ Requires: libvirt-libs = %{version}-%{release} %if 0%{?fedora} Requires: glusterfs-client >= 2.0.1 %endif - %if (0%{?fedora} || 0%{?with_storage_gluster}) + %if 0%{?fedora} || 0%{?with_storage_gluster} Requires: /usr/sbin/gluster %endif -- 2.41.0

To make things more readable, use the same order (%pre, %post, %posttrans, %preun, %postun) everywhere. Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- libvirt.spec.in | 104 ++++++++++++++++++++++++------------------------ 1 file changed, 52 insertions(+), 52 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 05e322492a..db8d9158ae 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1492,9 +1492,6 @@ fi \ %endif %libvirt_daemon_schedule_restart libvirtd -%preun daemon -%libvirt_daemon_systemd_preun_inet libvirtd - %posttrans daemon %libvirt_sysconfig_posttrans libvirtd if test %libvirt_daemon_needs_restart libvirtd @@ -1531,6 +1528,9 @@ then fi %libvirt_daemon_finish_restart libvirtd +%preun daemon +%libvirt_daemon_systemd_preun_inet libvirtd + %pre daemon-common %libvirt_sysconfig_pre libvirt-guests # 'libvirt' group is just to allow password-less polkit access to libvirt @@ -1541,6 +1541,9 @@ exit 0 %post daemon-common %systemd_post libvirt-guests.service +%posttrans daemon-common +%libvirt_sysconfig_posttrans libvirt-guests + %preun daemon-common %systemd_preun libvirt-guests.service @@ -1548,15 +1551,15 @@ exit 0 /bin/systemctl daemon-reload >/dev/null 2>&1 || : %systemd_postun libvirt-guests.service -%posttrans daemon-common -%libvirt_sysconfig_posttrans libvirt-guests - %pre daemon-lock %libvirt_sysconfig_pre virtlockd %post daemon-lock %libvirt_daemon_systemd_post_priv virtlockd +%posttrans daemon-lock +%libvirt_sysconfig_posttrans virtlockd + %preun daemon-lock %libvirt_daemon_systemd_preun_priv virtlockd @@ -1566,15 +1569,15 @@ if [ $1 -ge 1 ] ; then /bin/systemctl reload-or-try-restart virtlockd.service >/dev/null 2>&1 || : fi -%posttrans daemon-lock -%libvirt_sysconfig_posttrans virtlockd - %pre daemon-log %libvirt_sysconfig_pre virtlogd %post daemon-log %libvirt_daemon_systemd_post_priv virtlogd +%posttrans daemon-log +%libvirt_sysconfig_posttrans virtlogd + %preun daemon-log %libvirt_daemon_systemd_preun_priv virtlogd @@ -1584,9 +1587,6 @@ if [ $1 -ge 1 ] ; then /bin/systemctl reload-or-try-restart virtlogd.service >/dev/null 2>&1 || : fi -%posttrans daemon-log -%libvirt_sysconfig_posttrans virtlogd - %pre daemon-proxy %libvirt_sysconfig_pre virtproxyd @@ -1595,12 +1595,12 @@ fi %libvirt_daemon_systemd_post_inet virtproxyd %endif -%preun daemon-proxy -%libvirt_daemon_systemd_preun_inet virtproxyd - %posttrans daemon-proxy %libvirt_sysconfig_posttrans virtproxyd +%preun daemon-proxy +%libvirt_daemon_systemd_preun_inet virtproxyd + %pre daemon-driver-network %libvirt_sysconfig_pre virtnetworkd @@ -1614,6 +1614,10 @@ fi %endif %libvirt_daemon_schedule_restart virtnetworkd +%posttrans daemon-driver-network +%libvirt_sysconfig_posttrans virtnetworkd +%libvirt_daemon_perform_restart virtnetworkd + %preun daemon-driver-network %libvirt_daemon_systemd_preun virtnetworkd @@ -1622,10 +1626,6 @@ fi %firewalld_reload %endif -%posttrans daemon-driver-network -%libvirt_sysconfig_posttrans virtnetworkd -%libvirt_daemon_perform_restart virtnetworkd - %pre daemon-driver-nwfilter %libvirt_sysconfig_pre virtnwfilterd @@ -1635,13 +1635,13 @@ fi %endif %libvirt_daemon_schedule_restart virtnwfilterd -%preun daemon-driver-nwfilter -%libvirt_daemon_systemd_preun virtnwfilterd - %posttrans daemon-driver-nwfilter %libvirt_sysconfig_posttrans virtnwfilterd %libvirt_daemon_perform_restart virtnwfilterd +%preun daemon-driver-nwfilter +%libvirt_daemon_systemd_preun virtnwfilterd + %pre daemon-driver-nodedev %libvirt_sysconfig_pre virtnodedevd @@ -1651,13 +1651,13 @@ fi %endif %libvirt_daemon_schedule_restart virtnodedevd -%preun daemon-driver-nodedev -%libvirt_daemon_systemd_preun virtnodedevd - %posttrans daemon-driver-nodedev %libvirt_sysconfig_posttrans virtnodedevd %libvirt_daemon_perform_restart virtnodedevd +%preun daemon-driver-nodedev +%libvirt_daemon_systemd_preun virtnodedevd + %pre daemon-driver-interface %libvirt_sysconfig_pre virtinterfaced @@ -1667,13 +1667,13 @@ fi %endif %libvirt_daemon_schedule_restart virtinterfaced -%preun daemon-driver-interface -%libvirt_daemon_systemd_preun virtinterfaced - %posttrans daemon-driver-interface %libvirt_sysconfig_posttrans virtinterfaced %libvirt_daemon_perform_restart virtinterfaced +%preun daemon-driver-interface +%libvirt_daemon_systemd_preun virtinterfaced + %pre daemon-driver-secret %libvirt_sysconfig_pre virtsecretd @@ -1683,13 +1683,13 @@ fi %endif %libvirt_daemon_schedule_restart virtsecretd -%preun daemon-driver-secret -%libvirt_daemon_systemd_preun virtsecretd - %posttrans daemon-driver-secret %libvirt_sysconfig_posttrans virtsecretd %libvirt_daemon_perform_restart virtsecretd +%preun daemon-driver-secret +%libvirt_daemon_systemd_preun virtsecretd + %pre daemon-driver-storage-core %libvirt_sysconfig_pre virtstoraged @@ -1699,13 +1699,13 @@ fi %endif %libvirt_daemon_schedule_restart virtstoraged -%preun daemon-driver-storage-core -%libvirt_daemon_systemd_preun virtstoraged - %posttrans daemon-driver-storage-core %libvirt_sysconfig_posttrans virtstoraged %libvirt_daemon_perform_restart virtstoraged +%preun daemon-driver-storage-core +%libvirt_daemon_systemd_preun virtstoraged + %if %{with_qemu} %pre daemon-driver-qemu %libvirt_sysconfig_pre virtqemud @@ -1729,12 +1729,12 @@ exit 0 %endif %libvirt_daemon_schedule_restart virtqemud -%preun daemon-driver-qemu -%libvirt_daemon_systemd_preun virtqemud - %posttrans daemon-driver-qemu %libvirt_sysconfig_posttrans virtqemud %libvirt_daemon_perform_restart virtqemud + +%preun daemon-driver-qemu +%libvirt_daemon_systemd_preun virtqemud %endif %if %{with_lxc} @@ -1747,48 +1747,48 @@ exit 0 %endif %libvirt_daemon_schedule_restart virtlxcd -%preun daemon-driver-lxc -%libvirt_daemon_systemd_preun virtlxcd - %posttrans daemon-driver-lxc %libvirt_sysconfig_posttrans virtlxcd %libvirt_daemon_perform_restart virtlxcd + +%preun daemon-driver-lxc +%libvirt_daemon_systemd_preun virtlxcd %endif %if %{with_vbox} +%pre daemon-driver-vbox +%libvirt_sysconfig_pre virtvboxd + %post daemon-driver-vbox %if %{with_modular_daemons} %libvirt_daemon_systemd_post virtvboxd %endif %libvirt_daemon_schedule_restart virtvboxd -%pre daemon-driver-vbox -%libvirt_sysconfig_pre virtvboxd - -%preun daemon-driver-vbox -%libvirt_daemon_systemd_preun virtvboxd - %posttrans daemon-driver-vbox %libvirt_sysconfig_posttrans virtvboxd %libvirt_daemon_perform_restart virtvboxd + +%preun daemon-driver-vbox +%libvirt_daemon_systemd_preun virtvboxd %endif %if %{with_libxl} +%pre daemon-driver-libxl +%libvirt_sysconfig_pre virtxend + %post daemon-driver-libxl %if %{with_modular_daemons} %libvirt_daemon_systemd_post virtxend %endif %libvirt_daemon_schedule_restart virtxend -%pre daemon-driver-libxl -%libvirt_sysconfig_pre virtxend - -%preun daemon-driver-libxl -%libvirt_daemon_systemd_preun virtxend - %posttrans daemon-driver-libxl %libvirt_sysconfig_posttrans virtxend %libvirt_daemon_perform_restart virtxend + +%preun daemon-driver-libxl +%libvirt_daemon_systemd_preun virtxend %endif %post daemon-config-network -- 2.41.0

On Fri, Jul 14, 2023 at 04:39:37PM +0200, Andrea Bolognani wrote:
To make things more readable, use the same order (%pre, %post, %posttrans, %preun, %postun) everywhere.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>

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

This logic was necessary when socket activation was introduced in libvirt 5.6.0/5.7.0 in order to guarantee smooth upgrades. These days, even the oldest platform that we target ships a version of libvirtd that implements socket activation, so the additional code is no longer useful and we can treat libvirtd the same as all other services. Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- libvirt.spec.in | 34 +--------------------------------- 1 file changed, 1 insertion(+), 33 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index c9317ed0cc..d09c3b3340 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1492,39 +1492,7 @@ fi \ %posttrans daemon %libvirt_sysconfig_posttrans libvirtd -if test %libvirt_daemon_needs_restart libvirtd -then - # See if user has previously modified their install to - # tell libvirtd to use --listen - grep -E '^LIBVIRTD_ARGS=.*--listen' /etc/sysconfig/libvirtd 1>/dev/null 2>&1 - if test $? = 0 - then - # Then lets keep honouring --listen and *not* use - # systemd socket activation, because switching things - # might confuse mgmt tool like puppet/ansible that - # expect the old style libvirtd - /bin/systemctl mask \ - libvirtd.socket \ - libvirtd-ro.socket \ - libvirtd-admin.socket \ - libvirtd-tls.socket \ - libvirtd-tcp.socket >/dev/null 2>&1 || : - /bin/systemctl try-restart libvirtd.service >/dev/null 2>&1 || : - else - # Old libvirtd owns the sockets and will delete them on - # shutdown. Can't use a try-restart as libvirtd will simply - # own the sockets again when it comes back up. Thus we must - # do this particular ordering, so that we get libvirtd - # running with socket activation in use - /bin/systemctl stop libvirtd.service >/dev/null 2>&1 || : - /bin/systemctl try-restart \ - libvirtd.socket \ - libvirtd-ro.socket \ - libvirtd-admin.socket >/dev/null 2>&1 || : - /bin/systemctl start libvirtd.service >/dev/null 2>&1 || : - fi -fi -%libvirt_daemon_finish_restart libvirtd +%libvirt_daemon_perform_restart libvirtd %preun daemon %libvirt_daemon_systemd_preun_inet libvirtd -- 2.41.0

On Fri, Jul 14, 2023 at 04:39:39PM +0200, Andrea Bolognani wrote:
This logic was necessary when socket activation was introduced in libvirt 5.6.0/5.7.0 in order to guarantee smooth upgrades.
These days, even the oldest platform that we target ships a version of libvirtd that implements socket activation, so the additional code is no longer useful and we can treat libvirtd the same as all other services.
The upgrade path though can come from a platform that we don't support, but we do support upgrade from. eg we don't support RHEL-8, but upgrades from 8 -> 9 are supported. I think it is premature to declare this upgrade code no longer useful.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- libvirt.spec.in | 34 +--------------------------------- 1 file changed, 1 insertion(+), 33 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in index c9317ed0cc..d09c3b3340 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1492,39 +1492,7 @@ fi \
%posttrans daemon %libvirt_sysconfig_posttrans libvirtd -if test %libvirt_daemon_needs_restart libvirtd -then - # See if user has previously modified their install to - # tell libvirtd to use --listen - grep -E '^LIBVIRTD_ARGS=.*--listen' /etc/sysconfig/libvirtd 1>/dev/null 2>&1 - if test $? = 0 - then - # Then lets keep honouring --listen and *not* use - # systemd socket activation, because switching things - # might confuse mgmt tool like puppet/ansible that - # expect the old style libvirtd - /bin/systemctl mask \ - libvirtd.socket \ - libvirtd-ro.socket \ - libvirtd-admin.socket \ - libvirtd-tls.socket \ - libvirtd-tcp.socket >/dev/null 2>&1 || : - /bin/systemctl try-restart libvirtd.service >/dev/null 2>&1 || : - else - # Old libvirtd owns the sockets and will delete them on - # shutdown. Can't use a try-restart as libvirtd will simply - # own the sockets again when it comes back up. Thus we must - # do this particular ordering, so that we get libvirtd - # running with socket activation in use - /bin/systemctl stop libvirtd.service >/dev/null 2>&1 || : - /bin/systemctl try-restart \ - libvirtd.socket \ - libvirtd-ro.socket \ - libvirtd-admin.socket >/dev/null 2>&1 || : - /bin/systemctl start libvirtd.service >/dev/null 2>&1 || : - fi -fi -%libvirt_daemon_finish_restart libvirtd +%libvirt_daemon_perform_restart libvirtd
%preun daemon %libvirt_daemon_systemd_preun_inet libvirtd -- 2.41.0
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 Fri, Jul 14, 2023 at 03:45:11PM +0100, Daniel P. Berrangé wrote:
On Fri, Jul 14, 2023 at 04:39:39PM +0200, Andrea Bolognani wrote:
This logic was necessary when socket activation was introduced in libvirt 5.6.0/5.7.0 in order to guarantee smooth upgrades.
These days, even the oldest platform that we target ships a version of libvirtd that implements socket activation, so the additional code is no longer useful and we can treat libvirtd the same as all other services.
The upgrade path though can come from a platform that we don't support, but we do support upgrade from.
eg we don't support RHEL-8, but upgrades from 8 -> 9 are supported. I think it is premature to declare this upgrade code no longer useful.
We do target RHEL 8 still :) RHEL 8 got libvirt 6.0.0, which comes with socket activation support, back in 2020 with RHEL 8.3. Based on our support policy we only consider the latest point release a valid target anyway, but in this case we should absolutely be in the clear. -- Andrea Bolognani / Red Hat / Virtualization

On Fri, Jul 14, 2023 at 08:13:11AM -0700, Andrea Bolognani wrote:
On Fri, Jul 14, 2023 at 03:45:11PM +0100, Daniel P. Berrangé wrote:
On Fri, Jul 14, 2023 at 04:39:39PM +0200, Andrea Bolognani wrote:
This logic was necessary when socket activation was introduced in libvirt 5.6.0/5.7.0 in order to guarantee smooth upgrades.
These days, even the oldest platform that we target ships a version of libvirtd that implements socket activation, so the additional code is no longer useful and we can treat libvirtd the same as all other services.
The upgrade path though can come from a platform that we don't support, but we do support upgrade from.
eg we don't support RHEL-8, but upgrades from 8 -> 9 are supported. I think it is premature to declare this upgrade code no longer useful.
We do target RHEL 8 still :)
/facepalm
RHEL 8 got libvirt 6.0.0, which comes with socket activation support, back in 2020 with RHEL 8.3. Based on our support policy we only consider the latest point release a valid target anyway, but in this case we should absolutely be in the clear.
I'm still not convinced that makes this obsolete though. We introduced it but that's not ensuring every deployment is actually using it. We spent some time explaining to people how to stick with non-activation scenarios if they weren't ready to change things like ansible admin scripts from earlier RHEL-8.x Of course with any distro version at all, people could have turned off activation, but with RHEL-9 I'd be more comfortable saying it is unlikely because activation was the default from day 1, unlike 8. 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 Fri, Jul 14, 2023 at 04:25:48PM +0100, Daniel P. Berrangé wrote:
On Fri, Jul 14, 2023 at 08:13:11AM -0700, Andrea Bolognani wrote:
RHEL 8 got libvirt 6.0.0, which comes with socket activation support, back in 2020 with RHEL 8.3. Based on our support policy we only consider the latest point release a valid target anyway, but in this case we should absolutely be in the clear.
I'm still not convinced that makes this obsolete though.
We introduced it but that's not ensuring every deployment is actually using it. We spent some time explaining to people how to stick with non-activation scenarios if they weren't ready to change things like ansible admin scripts from earlier RHEL-8.x
Of course with any distro version at all, people could have turned off activation, but with RHEL-9 I'd be more comfortable saying it is unlikely because activation was the default from day 1, unlike 8.
Just to make sure we're on the same page. The code I'm deleting looks like this: # See if user has previously modified their install to # tell libvirtd to use --listen grep -E '^LIBVIRTD_ARGS=.*--listen' /etc/sysconfig/libvirtd 1>/dev/null 2>&1 if test $? = 0 then # Then lets keep honouring --listen and *not* use # systemd socket activation, because switching things # might confuse mgmt tool like puppet/ansible that # expect the old style libvirtd /bin/systemctl mask \ libvirtd.socket \ libvirtd-ro.socket \ libvirtd-admin.socket \ libvirtd-tls.socket \ libvirtd-tcp.socket >/dev/null 2>&1 || : /bin/systemctl try-restart libvirtd.service >/dev/null 2>&1 || : else # Old libvirtd owns the sockets and will delete them on # shutdown. Can't use a try-restart as libvirtd will simply # own the sockets again when it comes back up. Thus we must # do this particular ordering, so that we get libvirtd # running with socket activation in use /bin/systemctl stop libvirtd.service >/dev/null 2>&1 || : /bin/systemctl try-restart \ libvirtd.socket \ libvirtd-ro.socket \ libvirtd-admin.socket >/dev/null 2>&1 || : /bin/systemctl start libvirtd.service >/dev/null 2>&1 || : fi The 'else' branch deals with switching libvirtd < 5.6.0 to use proper socket activation. All of our targets come with much newer versions of libvirt at this point, so either they already had socket activation enabled out of the box or they must have been switched over by now. Which makes at least this branch obsolete, agreed? The 'if' branch deals with the scenario in which --listen has been configured, which is a non-default configuration that we don't want to mess with. Fair enough. But, for that configuration to work at all, the various sockets must have already been masked, either by some deploy-time automation or by this scriptlet running at some point between when libvirt < 5.6.0 was installed and now. And since we're not touching socket during upgrades from the regular %libvirt_daemon_perform_restart macro anyway, we can't really mess this stuff up. So, what scenario are you concerned with? -- Andrea Bolognani / Red Hat / Virtualization

On Fri, Jul 14, 2023 at 08:44:04AM -0700, Andrea Bolognani wrote:
On Fri, Jul 14, 2023 at 04:25:48PM +0100, Daniel P. Berrangé wrote:
On Fri, Jul 14, 2023 at 08:13:11AM -0700, Andrea Bolognani wrote:
RHEL 8 got libvirt 6.0.0, which comes with socket activation support, back in 2020 with RHEL 8.3. Based on our support policy we only consider the latest point release a valid target anyway, but in this case we should absolutely be in the clear.
I'm still not convinced that makes this obsolete though.
We introduced it but that's not ensuring every deployment is actually using it. We spent some time explaining to people how to stick with non-activation scenarios if they weren't ready to change things like ansible admin scripts from earlier RHEL-8.x
Of course with any distro version at all, people could have turned off activation, but with RHEL-9 I'd be more comfortable saying it is unlikely because activation was the default from day 1, unlike 8.
Just to make sure we're on the same page. The code I'm deleting looks like this:
# See if user has previously modified their install to # tell libvirtd to use --listen grep -E '^LIBVIRTD_ARGS=.*--listen' /etc/sysconfig/libvirtd 1>/dev/null 2>&1 if test $? = 0 then # Then lets keep honouring --listen and *not* use # systemd socket activation, because switching things # might confuse mgmt tool like puppet/ansible that # expect the old style libvirtd /bin/systemctl mask \ libvirtd.socket \ libvirtd-ro.socket \ libvirtd-admin.socket \ libvirtd-tls.socket \ libvirtd-tcp.socket >/dev/null 2>&1 || : /bin/systemctl try-restart libvirtd.service >/dev/null 2>&1 || : else # Old libvirtd owns the sockets and will delete them on # shutdown. Can't use a try-restart as libvirtd will simply # own the sockets again when it comes back up. Thus we must # do this particular ordering, so that we get libvirtd # running with socket activation in use /bin/systemctl stop libvirtd.service >/dev/null 2>&1 || : /bin/systemctl try-restart \ libvirtd.socket \ libvirtd-ro.socket \ libvirtd-admin.socket >/dev/null 2>&1 || : /bin/systemctl start libvirtd.service >/dev/null 2>&1 || : fi
The 'else' branch deals with switching libvirtd < 5.6.0 to use proper socket activation. All of our targets come with much newer versions of libvirt at this point, so either they already had socket activation enabled out of the box or they must have been switched over by now. Which makes at least this branch obsolete, agreed?
The 'if' branch deals with the scenario in which --listen has been configured, which is a non-default configuration that we don't want to mess with. Fair enough. But, for that configuration to work at all, the various sockets must have already been masked, either by some deploy-time automation or by this scriptlet running at some point between when libvirt < 5.6.0 was installed and now. And since we're not touching socket during upgrades from the regular %libvirt_daemon_perform_restart macro anyway, we can't really mess this stuff up.
Ok, so its only a problem if they are still running < 5.6.0 when they upgrade, which is probably an unreasonably upgrade gap to be credibly concerned about. 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 Fri, Jul 14, 2023 at 04:39:39PM +0200, Andrea Bolognani wrote:
This logic was necessary when socket activation was introduced in libvirt 5.6.0/5.7.0 in order to guarantee smooth upgrades.
These days, even the oldest platform that we target ships a version of libvirtd that implements socket activation, so the additional code is no longer useful and we can treat libvirtd the same as all other services.
On top of that it was also a little bit fragile. At least from myself, I am fine with this. Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- libvirt.spec.in | 34 +--------------------------------- 1 file changed, 1 insertion(+), 33 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in index c9317ed0cc..d09c3b3340 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1492,39 +1492,7 @@ fi \
%posttrans daemon %libvirt_sysconfig_posttrans libvirtd -if test %libvirt_daemon_needs_restart libvirtd -then - # See if user has previously modified their install to - # tell libvirtd to use --listen - grep -E '^LIBVIRTD_ARGS=.*--listen' /etc/sysconfig/libvirtd 1>/dev/null 2>&1 - if test $? = 0 - then - # Then lets keep honouring --listen and *not* use - # systemd socket activation, because switching things - # might confuse mgmt tool like puppet/ansible that - # expect the old style libvirtd - /bin/systemctl mask \ - libvirtd.socket \ - libvirtd-ro.socket \ - libvirtd-admin.socket \ - libvirtd-tls.socket \ - libvirtd-tcp.socket >/dev/null 2>&1 || : - /bin/systemctl try-restart libvirtd.service >/dev/null 2>&1 || : - else - # Old libvirtd owns the sockets and will delete them on - # shutdown. Can't use a try-restart as libvirtd will simply - # own the sockets again when it comes back up. Thus we must - # do this particular ordering, so that we get libvirtd - # running with socket activation in use - /bin/systemctl stop libvirtd.service >/dev/null 2>&1 || : - /bin/systemctl try-restart \ - libvirtd.socket \ - libvirtd-ro.socket \ - libvirtd-admin.socket >/dev/null 2>&1 || : - /bin/systemctl start libvirtd.service >/dev/null 2>&1 || : - fi -fi -%libvirt_daemon_finish_restart libvirtd +%libvirt_daemon_perform_restart libvirtd
%preun daemon %libvirt_daemon_systemd_preun_inet libvirtd -- 2.41.0

systemd provides a number of standard RPM macros but they don't quite satisfy our requirements, as evidenced by the fact that we have already built some custom tooling around them. Scenarios that the standard macros don't cover and that we're already addressing with our custom ones: * for some services (libvirtd, virtnetworkd, virtnwfilterd) there are multiple conditions that might lead to a restart, and we want to make sure that they're not needlessly restarted several times per transaction; * some services (virtlogd, virtlockd) must not be restarted during upgrade, so we have to reload them instead. Issues that neither the standard macros nor our custom ones address: * presets for units should be applied then the unit is first installed, not when the package that contains it is. The package split that happened in 9.1.0 highlighted why this last point is so important: when virtproxyd and its sockets were moved from libvirt-daemon to the new libvirt-daemon-proxy package, upgrades from 9.0.0 caused presets for them to be applied. On a platform such as Fedora, where modular daemons are the default, this has resulted in breaking existing deployments in at least two scenarios. The first one is machines that were configured to use the monolithic daemon, either because the local admin had manually changed the configuration or because the installation dated back to before modular daemons had become the default. In this case, virtproxyd.socket being enabled resulted in a silent conflict with libvirtd.socket, which by design shares the same path, and thus a completely broken setup. The second one is machines where virtproxy-tls.socket, which is disabled by default, had manually been enabled: in this case, applying the presets resulted in it being disabled and thus a loss of remote availability. Note that these are just two concrete scenarios, but the problem is more generic. For example, if we were to add more units to an existing package, per the current approach they wouldn't have their presets applied. The new macros are designed to avoid all of the pitfalls mentioned above. As a bonus, they're also simpler to use: where the current approach requires restarts and other operations to be handled separately, the new one integrates the two so that, for each scriptlet, a single macro call is needed. https://bugzilla.redhat.com/show_bug.cgi?id=2210058 Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- libvirt.spec.in | 140 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 140 insertions(+) diff --git a/libvirt.spec.in b/libvirt.spec.in index d09c3b3340..a41800c273 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1471,18 +1471,158 @@ then \ fi \ %libvirt_daemon_finish_restart %1 +%define libvirt_rpmstatedir %{_localstatedir}/lib/rpm-state/libvirt + +# Mark units such that presets will later be applied to them. Meant +# to be called during %pre. Units that already exist on the system +# will not be marked, with the assumption that presets have already +# been applied at some point in the past. This makes it safe to call +# this macro for all units each time %pre runs. +%define libvirt_systemd_schedule_preset() \ + mkdir -p %{libvirt_rpmstatedir} || : \ + for unit in %{?*}; do \ + if ! test -e %{_unitdir}/$unit; then \ + touch %{libvirt_rpmstatedir}/preset-$unit || : \ + fi \ + done \ + %{nil} + +# Apply presets for units that have previously been marked. Meant to +# be called during %posttrans. Note that foo.service must be passed +# as the first argument, before all the various foo*.socket +# associated with it, for things to work correctly. This is necessary +# because Also=foo.socket is usually present in foo.service's +# [Install] section, and we want that configuration to take +# precedence over foo.socket's own presets. +%define libvirt_systemd_perform_preset() \ + %{?7:%{error:Too many arguments}} \ + for unit in %{?2} %{?3} %{?4} %{?5} %{?6} %1; do \ + if test -e %{libvirt_rpmstatedir}/preset-$unit; then \ + /usr/bin/systemctl --no-reload preset $unit || : \ + fi \ + rm -f %{libvirt_rpmstatedir}/preset-$unit \ + done \ + rmdir %{libvirt_rpmstatedir} 2>/dev/null || : \ + %{nil} + +# Mark a single unit for restart. Meant to be called during %pre. +%define libvirt_systemd_schedule_restart() \ + mkdir -p %{libvirt_rpmstatedir} || : \ + touch %{libvirt_rpmstatedir}/restart-%1 || : \ + %{nil} + +# Restart a unit that was previously marked. Meant to be called +# during %posttrans. If systemd is not running, no action will be +# performed. +%define libvirt_systemd_perform_restart() \ + if test -d /run/systemd/system && \ + test -e %{libvirt_rpmstatedir}/restart-%1; then \ + /usr/bin/systemctl try-restart %1 >/dev/null 2>&1 || : \ + fi \ + rm -f %{libvirt_rpmstatedir}/restart-%1 \ + rmdir %{libvirt_rpmstatedir} 2>/dev/null || : \ + %{nil} + +# Mark a single unit for reload. Meant to be called during %pre. +%define libvirt_systemd_schedule_reload() \ + mkdir -p %{libvirt_rpmstatedir} || : \ + touch %{libvirt_rpmstatedir}/reload-%1 || : \ + %{nil} + +# Reload a unit that was previously marked. Meant to be called during +# %posttrans. If systemd is not running, no action will be performed. +%define libvirt_systemd_perform_reload() \ + if test -d /run/systemd/system && \ + test -e %{libvirt_rpmstatedir}/reload-%1; then \ + /usr/bin/systemctl try-reload-or-restart %1 >/dev/null 2>&1 || : \ + fi \ + rm -f %{libvirt_rpmstatedir}/reload-%1 \ + rmdir %{libvirt_rpmstatedir} 2>/dev/null || : \ + %{nil} + +# Disable a single unit, optionally stopping it if systemd is +# running. Meant to be called during %preun. +%define libvirt_systemd_disable() \ + if test -d /run/systemd/system; then \ + /usr/bin/systemctl --no-reload disable --now %{?*} || : \ + else \ + /usr/bin/systemctl --no-reload disable %{?*} || : \ + fi \ + %{nil} + +# %pre implementation for services that should be restarted on +# upgrade. Note that foo.service must be passed as the first +# argument, before all the various foo*.socket associated with it. +%define libvirt_systemd_restart_pre() \ + %libvirt_systemd_schedule_preset %{?*} \ + %libvirt_systemd_schedule_restart %1 \ + %{nil} + +# %pre implementation for services that should be reloaded on +# upgrade. Note that foo.service must be passed as the first +# argument, before all the various foo*.socket associated with it. +%define libvirt_systemd_reload_pre() \ + %libvirt_systemd_schedule_preset %{?*} \ + %libvirt_systemd_schedule_reload %1 \ + %{nil} + +# %pre implementation for services that should be neither restarted +# nor reloaded on upgrade. +%define libvirt_systemd_noaction_pre() \ + %libvirt_systemd_schedule_preset %{?*} \ + %{nil} + +# %posttrans implementation for all services. We can use a single +# macro to cover all scenarios, because each operation will only be +# performed if it had previously been scheduled. Note that +# foo.service must be passed as the first argument, before all the +# various foo*.socket associated with it. +%define libvirt_systemd_posttrans() \ + %libvirt_systemd_perform_preset %{?*} \ + %libvirt_systemd_perform_reload %1 \ + %libvirt_systemd_perform_restart %1 \ + %{nil} + +# %preun implementation for all services. +%define libvirt_systemd_preun() \ + if [ $1 -lt 1 ]; then \ + %libvirt_systemd_disable %{?*} \ + fi \ + %{nil} + # For daemons with only UNIX sockets %define libvirt_daemon_systemd_post() %systemd_post %1.socket %1-ro.socket %1-admin.socket %1.service %define libvirt_daemon_systemd_preun() %systemd_preun %1.service %1-ro.socket %1-admin.socket %1.socket +%define libvirt_systemd_unix_pre() %libvirt_systemd_restart_pre %1.service %1.socket %1-ro.socket %1-admin.socket +%define libvirt_systemd_unix_posttrans() %libvirt_systemd_posttrans %1.service %1.socket %1-ro.socket %1-admin.socket +%define libvirt_systemd_unix_preun() %libvirt_systemd_preun %1.service %1.socket %1-ro.socket %1-admin.socket + # For daemons with UNIX and INET sockets %define libvirt_daemon_systemd_post_inet() %systemd_post %1.socket %1-ro.socket %1-admin.socket %1-tls.socket %1-tcp.socket %1.service %define libvirt_daemon_systemd_preun_inet() %systemd_preun %1.service %1-ro.socket %1-admin.socket %1-tls.socket %1-tcp.socket %1.socket +%define libvirt_systemd_inet_pre() %libvirt_systemd_restart_pre %1.service %1.socket %1-ro.socket %1-admin.socket %1-tls.socket %1-tcp.socket +%define libvirt_systemd_inet_posttrans() %libvirt_systemd_posttrans %1.service %1.socket %1-ro.socket %1-admin.socket %1-tls.socket %1-tcp.socket +%define libvirt_systemd_inet_preun() %libvirt_systemd_preun %1.service %1.socket %1-ro.socket %1-admin.socket %1-tls.socket %1-tcp.socket + # For daemons with only UNIX sockets and no unprivileged read-only access %define libvirt_daemon_systemd_post_priv() %systemd_post %1.socket %1-admin.socket %1.service %define libvirt_daemon_systemd_preun_priv() %systemd_preun %1.service %1-admin.socket %1.socket +%define libvirt_systemd_privileged_pre() %libvirt_systemd_reload_pre %1.service %1.socket %1-admin.socket +%define libvirt_systemd_privileged_posttrans() %libvirt_systemd_posttrans %1.service %1.socket %1-admin.socket +%define libvirt_systemd_privileged_preun() %libvirt_systemd_preun %1.service %1.socket %1-admin.socket + +# For one-shot daemons that have no associated sockets and should never be restarted +%define libvirt_systemd_oneshot_pre() %libvirt_systemd_noaction_pre %1.service +%define libvirt_systemd_oneshot_posttrans() %libvirt_systemd_posttrans %1.service +%define libvirt_systemd_oneshot_preun() %libvirt_systemd_preun %1.service + +# For packages that install configuration for other daemons +%define libvirt_systemd_config_pre() %libvirt_systemd_schedule_restart %1.service +%define libvirt_systemd_config_posttrans() %libvirt_systemd_perform_restart %1.service + %pre daemon %libvirt_sysconfig_pre libvirtd -- 2.41.0

On Fri, Jul 14, 2023 at 04:39:40PM +0200, Andrea Bolognani wrote:
systemd provides a number of standard RPM macros but they don't quite satisfy our requirements, as evidenced by the fact that we have already built some custom tooling around them.
Scenarios that the standard macros don't cover and that we're already addressing with our custom ones:
* for some services (libvirtd, virtnetworkd, virtnwfilterd) there are multiple conditions that might lead to a restart, and we want to make sure that they're not needlessly restarted several times per transaction;
* some services (virtlogd, virtlockd) must not be restarted during upgrade, so we have to reload them instead.
Issues that neither the standard macros nor our custom ones address:
* presets for units should be applied then the unit is first
s/then/when
installed, not when the package that contains it is.
The package split that happened in 9.1.0 highlighted why this last point is so important: when virtproxyd and its sockets were moved from libvirt-daemon to the new libvirt-daemon-proxy package, upgrades from 9.0.0 caused presets for them to be applied.
On a platform such as Fedora, where modular daemons are the default, this has resulted in breaking existing deployments in at least two scenarios.
The first one is machines that were configured to use the monolithic daemon, either because the local admin had manually changed the configuration or because the installation dated back to before modular daemons had become the default. In this case, virtproxyd.socket being enabled resulted in a silent conflict with libvirtd.socket, which by design shares the same path, and thus a completely broken setup.
The second one is machines where virtproxy-tls.socket, which is disabled by default, had manually been enabled: in this case, applying the presets resulted in it being disabled and thus a loss of remote availability.
Note that these are just two concrete scenarios, but the problem is more generic. For example, if we were to add more units to an existing package, per the current approach they wouldn't have their presets applied.
The new macros are designed to avoid all of the pitfalls mentioned above. As a bonus, they're also simpler to use: where the current approach requires restarts and other operations to be handled separately, the new one integrates the two so that, for each scriptlet, a single macro call is needed.
Even though this is suboptimal, I agree, it is a better solution than waiting for this to be dealt with in fedora/systemd. Sure, there are various ways to do this, triggers, markers, etc. but the one you chose seems least error prone and most readable. At least for now. I, myself, would prefer this to be merged and then possibly cleaned up once upstream has a better solution.
https://bugzilla.redhat.com/show_bug.cgi?id=2210058
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>

In most cases the replacement is straightforward, with the biggest difference being that we now schedule restarts during %pre instead of %post. This also means that we can get rid of %post for most packages, reducing the number of scriptlets that need to run during install/upgrade. Notable exceptions are libvirt-guests.service, where we stop using the standard systemd macros to adopt our custom ones, as well as the virtlogd and virtlockd services, where the reload operation is moved from %postun to %posttrans. https://bugzilla.redhat.com/show_bug.cgi?id=2210058 Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- libvirt.spec.in | 168 +++++++++++++++++------------------------------- 1 file changed, 59 insertions(+), 109 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index a41800c273..d929170b2b 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -461,7 +461,8 @@ Requires: polkit >= 0.112 Requires: dmidecode %endif # For service management -Requires(post): /usr/bin/systemctl +Requires(posttrans): /usr/bin/systemctl +Requires(preun): /usr/bin/systemctl # libvirtd depends on 'messagebus' service Requires: dbus # For uid creation during pre @@ -1625,103 +1626,78 @@ fi \ %pre daemon %libvirt_sysconfig_pre libvirtd - -%post daemon -%libvirt_daemon_systemd_post_inet libvirtd -%libvirt_daemon_schedule_restart libvirtd +%libvirt_systemd_inet_pre libvirtd %posttrans daemon %libvirt_sysconfig_posttrans libvirtd -%libvirt_daemon_perform_restart libvirtd +%libvirt_systemd_inet_posttrans libvirtd %preun daemon -%libvirt_daemon_systemd_preun_inet libvirtd +%libvirt_systemd_inet_preun libvirtd %pre daemon-common %libvirt_sysconfig_pre libvirt-guests +%libvirt_systemd_oneshot_pre libvirt-guests # 'libvirt' group is just to allow password-less polkit access to libvirt # daemons. The uid number is irrelevant, so we use dynamic allocation. getent group libvirt >/dev/null || groupadd -r libvirt exit 0 -%post daemon-common -%systemd_post libvirt-guests.service - %posttrans daemon-common %libvirt_sysconfig_posttrans libvirt-guests +%libvirt_systemd_oneshot_posttrans libvirt-guests %preun daemon-common -%systemd_preun libvirt-guests.service - -%postun daemon-common -/bin/systemctl daemon-reload >/dev/null 2>&1 || : -%systemd_postun libvirt-guests.service +%libvirt_systemd_oneshot_preun libvirt-guests %pre daemon-lock %libvirt_sysconfig_pre virtlockd - -%post daemon-lock -%libvirt_daemon_systemd_post_priv virtlockd +%libvirt_systemd_privileged_pre virtlockd %posttrans daemon-lock %libvirt_sysconfig_posttrans virtlockd +%libvirt_systemd_privileged_posttrans virtlockd %preun daemon-lock -%libvirt_daemon_systemd_preun_priv virtlockd - -%postun daemon-lock -/bin/systemctl daemon-reload >/dev/null 2>&1 || : -if [ $1 -ge 1 ] ; then - /bin/systemctl reload-or-try-restart virtlockd.service >/dev/null 2>&1 || : -fi +%libvirt_systemd_privileged_preun virtlockd %pre daemon-log %libvirt_sysconfig_pre virtlogd - -%post daemon-log -%libvirt_daemon_systemd_post_priv virtlogd +%libvirt_systemd_privileged_pre virtlogd %posttrans daemon-log %libvirt_sysconfig_posttrans virtlogd +%libvirt_systemd_privileged_posttrans virtlogd %preun daemon-log -%libvirt_daemon_systemd_preun_priv virtlogd - -%postun daemon-log -/bin/systemctl daemon-reload >/dev/null 2>&1 || : -if [ $1 -ge 1 ] ; then - /bin/systemctl reload-or-try-restart virtlogd.service >/dev/null 2>&1 || : -fi +%libvirt_systemd_privileged_preun virtlogd %pre daemon-proxy %libvirt_sysconfig_pre virtproxyd - -%post daemon-proxy -%libvirt_daemon_systemd_post_inet virtproxyd +%libvirt_systemd_inet_pre virtproxyd %posttrans daemon-proxy %libvirt_sysconfig_posttrans virtproxyd +%libvirt_systemd_inet_posttrans virtproxyd %preun daemon-proxy -%libvirt_daemon_systemd_preun_inet virtproxyd +%libvirt_systemd_inet_preun virtproxyd %pre daemon-driver-network %libvirt_sysconfig_pre virtnetworkd +%libvirt_systemd_unix_pre virtnetworkd %post daemon-driver-network %if %{with_firewalld_zone} %firewalld_reload %endif -%libvirt_daemon_systemd_post virtnetworkd -%libvirt_daemon_schedule_restart virtnetworkd - %posttrans daemon-driver-network %libvirt_sysconfig_posttrans virtnetworkd -%libvirt_daemon_perform_restart virtnetworkd +%libvirt_systemd_unix_posttrans virtnetworkd %preun daemon-driver-network -%libvirt_daemon_systemd_preun virtnetworkd +%libvirt_systemd_unix_preun virtnetworkd %postun daemon-driver-network %if %{with_firewalld_zone} @@ -1730,77 +1706,63 @@ fi %pre daemon-driver-nwfilter %libvirt_sysconfig_pre virtnwfilterd - -%post daemon-driver-nwfilter -%libvirt_daemon_systemd_post virtnwfilterd -%libvirt_daemon_schedule_restart virtnwfilterd +%libvirt_systemd_unix_pre virtnwfilterd %posttrans daemon-driver-nwfilter %libvirt_sysconfig_posttrans virtnwfilterd -%libvirt_daemon_perform_restart virtnwfilterd +%libvirt_systemd_unix_posttrans virtnwfilterd %preun daemon-driver-nwfilter -%libvirt_daemon_systemd_preun virtnwfilterd +%libvirt_systemd_unix_preun virtnwfilterd %pre daemon-driver-nodedev %libvirt_sysconfig_pre virtnodedevd - -%post daemon-driver-nodedev -%libvirt_daemon_systemd_post virtnodedevd -%libvirt_daemon_schedule_restart virtnodedevd +%libvirt_systemd_unix_pre virtnodedevd %posttrans daemon-driver-nodedev %libvirt_sysconfig_posttrans virtnodedevd -%libvirt_daemon_perform_restart virtnodedevd +%libvirt_systemd_unix_posttrans virtnodedevd %preun daemon-driver-nodedev -%libvirt_daemon_systemd_preun virtnodedevd +%libvirt_systemd_unix_preun virtnodedevd %pre daemon-driver-interface %libvirt_sysconfig_pre virtinterfaced - -%post daemon-driver-interface -%libvirt_daemon_systemd_post virtinterfaced -%libvirt_daemon_schedule_restart virtinterfaced +%libvirt_systemd_unix_pre virtinterfaced %posttrans daemon-driver-interface %libvirt_sysconfig_posttrans virtinterfaced -%libvirt_daemon_perform_restart virtinterfaced +%libvirt_systemd_unix_posttrans virtinterfaced %preun daemon-driver-interface -%libvirt_daemon_systemd_preun virtinterfaced +%libvirt_systemd_unix_preun virtinterfaced %pre daemon-driver-secret %libvirt_sysconfig_pre virtsecretd - -%post daemon-driver-secret -%libvirt_daemon_systemd_post virtsecretd -%libvirt_daemon_schedule_restart virtsecretd +%libvirt_systemd_unix_pre virsecretd %posttrans daemon-driver-secret %libvirt_sysconfig_posttrans virtsecretd -%libvirt_daemon_perform_restart virtsecretd +%libvirt_systemd_unix_posttrans virsecretd %preun daemon-driver-secret -%libvirt_daemon_systemd_preun virtsecretd +%libvirt_systemd_unix_preun virsecretd %pre daemon-driver-storage-core %libvirt_sysconfig_pre virtstoraged - -%post daemon-driver-storage-core -%libvirt_daemon_systemd_post virtstoraged -%libvirt_daemon_schedule_restart virtstoraged +%libvirt_systemd_unix_pre virtstoraged %posttrans daemon-driver-storage-core %libvirt_sysconfig_posttrans virtstoraged -%libvirt_daemon_perform_restart virtstoraged +%libvirt_systemd_unix_posttrans virtstoraged %preun daemon-driver-storage-core -%libvirt_daemon_systemd_preun virtstoraged +%libvirt_systemd_unix_preun virtstoraged %if %{with_qemu} %pre daemon-driver-qemu %libvirt_sysconfig_pre virtqemud +%libvirt_systemd_unix_pre virtqemud # We want soft static allocation of well-known ids, as disk images # are commonly shared across NFS mounts by id rather than name; see # https://fedoraproject.org/wiki/Packaging:UsersAndGroups @@ -1815,66 +1777,57 @@ if ! getent passwd qemu >/dev/null; then fi exit 0 -%post daemon-driver-qemu -%libvirt_daemon_systemd_post virtqemud -%libvirt_daemon_schedule_restart virtqemud - %posttrans daemon-driver-qemu %libvirt_sysconfig_posttrans virtqemud -%libvirt_daemon_perform_restart virtqemud +%libvirt_systemd_unix_posttrans virtqemud %preun daemon-driver-qemu -%libvirt_daemon_systemd_preun virtqemud +%libvirt_systemd_unix_preun virtqemud %endif %if %{with_lxc} %pre daemon-driver-lxc %libvirt_sysconfig_pre virtlxcd - -%post daemon-driver-lxc -%libvirt_daemon_systemd_post virtlxcd -%libvirt_daemon_schedule_restart virtlxcd +%libvirt_systemd_unix_pre virtlxcd %posttrans daemon-driver-lxc %libvirt_sysconfig_posttrans virtlxcd -%libvirt_daemon_perform_restart virtlxcd +%libvirt_systemd_unix_posttrans virtlxcd %preun daemon-driver-lxc -%libvirt_daemon_systemd_preun virtlxcd +%libvirt_systemd_unix_preun virtlxcd %endif %if %{with_vbox} %pre daemon-driver-vbox %libvirt_sysconfig_pre virtvboxd - -%post daemon-driver-vbox -%libvirt_daemon_systemd_post virtvboxd -%libvirt_daemon_schedule_restart virtvboxd +%libvirt_systemd_unix_pre virtvboxd %posttrans daemon-driver-vbox %libvirt_sysconfig_posttrans virtvboxd -%libvirt_daemon_perform_restart virtvboxd +%libvirt_systemd_unix_posttrans virtvboxd %preun daemon-driver-vbox -%libvirt_daemon_systemd_preun virtvboxd +%libvirt_systemd_unix_preun virtvboxd %endif %if %{with_libxl} %pre daemon-driver-libxl %libvirt_sysconfig_pre virtxend - -%post daemon-driver-libxl -%libvirt_daemon_systemd_post virtxend -%libvirt_daemon_schedule_restart virtxend +%libvirt_systemd_unix_pre virtxend %posttrans daemon-driver-libxl %libvirt_sysconfig_posttrans virtxend -%libvirt_daemon_perform_restart virtxend +%libvirt_systemd_unix_posttrans virtxend %preun daemon-driver-libxl -%libvirt_daemon_systemd_preun virtxend +%libvirt_systemd_unix_preun virtxend %endif +%pre daemon-config-network +%libvirt_systemd_config_pre libvirtd +%libvirt_systemd_config_pre virtnetworkd + %post daemon-config-network if test $1 -eq 1 && test ! -f %{_sysconfdir}/libvirt/qemu/networks/default.xml ; then # see if the network used by default network creates a conflict, @@ -1911,15 +1864,15 @@ if test $1 -eq 1 && test ! -f %{_sysconfdir}/libvirt/qemu/networks/default.xml ; ln -s ../default.xml %{_sysconfdir}/libvirt/qemu/networks/autostart/default.xml # libvirt saves this file with mode 0600 chmod 0600 %{_sysconfdir}/libvirt/qemu/networks/default.xml - - # Make sure libvirt picks up the new network defininiton - %libvirt_daemon_schedule_restart libvirtd - %libvirt_daemon_schedule_restart virtnetworkd fi %posttrans daemon-config-network -%libvirt_daemon_perform_restart libvirtd -%libvirt_daemon_perform_restart virtnetworkd +%libvirt_systemd_config_posttrans libvirtd +%libvirt_systemd_config_posttrans virtnetworkd + +%pre daemon-config-nwfilter +%libvirt_systemd_config_pre libvirtd +%libvirt_systemd_config_pre virtnwfilterd %post daemon-config-nwfilter for datadir_file in %{_datadir}/libvirt/nwfilter/*.xml; do @@ -1929,13 +1882,10 @@ for datadir_file in %{_datadir}/libvirt/nwfilter/*.xml; do install -m 0600 "$datadir_file" "$sysconfdir_file" fi done -# Make sure libvirt picks up the new nwfilter defininitons -%libvirt_daemon_schedule_restart libvirtd -%libvirt_daemon_schedule_restart virtnwfilterd %posttrans daemon-config-nwfilter -%libvirt_daemon_perform_restart libvirtd -%libvirt_daemon_perform_restart virtnwfilterd +%libvirt_systemd_config_posttrans libvirtd +%libvirt_systemd_config_posttrans virtnwfilterd %if %{with_lxc} %pre login-shell -- 2.41.0

On Fri, Jul 14, 2023 at 04:39:41PM +0200, Andrea Bolognani wrote:
In most cases the replacement is straightforward, with the biggest difference being that we now schedule restarts during %pre instead of %post. This also means that we can get rid of %post for most packages, reducing the number of scriptlets that need to run during install/upgrade.
Notable exceptions are libvirt-guests.service, where we stop using the standard systemd macros to adopt our custom ones, as well as the virtlogd and virtlockd services, where the reload operation is moved from %postun to %posttrans.
That would mean the reload is called on package install, but that's still better than nothing. Feel free to add [ "$1" -gt 1 ] around it somewhere if you want, but I don't think that's necessary. Reviewed-by: Martin Kletzander <mkletzan@redhat.com>

On Tue, Jul 25, 2023 at 03:52:08PM +0200, Martin Kletzander wrote:
On Fri, Jul 14, 2023 at 04:39:41PM +0200, Andrea Bolognani wrote:
In most cases the replacement is straightforward, with the biggest difference being that we now schedule restarts during %pre instead of %post. This also means that we can get rid of %post for most packages, reducing the number of scriptlets that need to run during install/upgrade.
Notable exceptions are libvirt-guests.service, where we stop using the standard systemd macros to adopt our custom ones, as well as the virtlogd and virtlockd services, where the reload operation is moved from %postun to %posttrans.
That would mean the reload is called on package install, but that's still better than nothing. Feel free to add [ "$1" -gt 1 ] around it somewhere if you want, but I don't think that's necessary.
We call 'systemctl try-reload-or-restart', which means that the unit will only be reloaded if it's already running. So, during the initial install, nothing will happen, and a reload will only be performed on upgrade *and* if the service is not in stopped state. Same thing for restarts. In other words, I don't think checking $1 is necessary either :) -- Andrea Bolognani / Red Hat / Virtualization

Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- libvirt.spec.in | 23 ----------------------- 1 file changed, 23 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index d929170b2b..17d5f5ff4a 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1457,21 +1457,6 @@ rm -rf $RPM_BUILD_ROOT%{mingw64_libexecdir}/libvirt-guests.sh # raising the test timeout VIR_TEST_DEBUG=1 %meson_test --no-suite syntax-check --timeout-multiplier 10 -%define libvirt_daemon_schedule_restart() mkdir -p %{_localstatedir}/lib/rpm-state/libvirt || : \ -/bin/systemctl is-active %1.service 1>/dev/null 2>&1 && \ - touch %{_localstatedir}/lib/rpm-state/libvirt/restart-%1 || : - -%define libvirt_daemon_finish_restart() rm -f %{_localstatedir}/lib/rpm-state/libvirt/restart-%1 \ -rmdir %{_localstatedir}/lib/rpm-state/libvirt 2>/dev/null || : - -%define libvirt_daemon_needs_restart() -f %{_localstatedir}/lib/rpm-state/libvirt/restart-%1 - -%define libvirt_daemon_perform_restart() if test %libvirt_daemon_needs_restart %1 \ -then \ - /bin/systemctl try-restart %1.service >/dev/null 2>&1 || : \ -fi \ -%libvirt_daemon_finish_restart %1 - %define libvirt_rpmstatedir %{_localstatedir}/lib/rpm-state/libvirt # Mark units such that presets will later be applied to them. Meant @@ -1592,25 +1577,17 @@ fi \ %{nil} # For daemons with only UNIX sockets -%define libvirt_daemon_systemd_post() %systemd_post %1.socket %1-ro.socket %1-admin.socket %1.service -%define libvirt_daemon_systemd_preun() %systemd_preun %1.service %1-ro.socket %1-admin.socket %1.socket %define libvirt_systemd_unix_pre() %libvirt_systemd_restart_pre %1.service %1.socket %1-ro.socket %1-admin.socket %define libvirt_systemd_unix_posttrans() %libvirt_systemd_posttrans %1.service %1.socket %1-ro.socket %1-admin.socket %define libvirt_systemd_unix_preun() %libvirt_systemd_preun %1.service %1.socket %1-ro.socket %1-admin.socket # For daemons with UNIX and INET sockets -%define libvirt_daemon_systemd_post_inet() %systemd_post %1.socket %1-ro.socket %1-admin.socket %1-tls.socket %1-tcp.socket %1.service -%define libvirt_daemon_systemd_preun_inet() %systemd_preun %1.service %1-ro.socket %1-admin.socket %1-tls.socket %1-tcp.socket %1.socket - %define libvirt_systemd_inet_pre() %libvirt_systemd_restart_pre %1.service %1.socket %1-ro.socket %1-admin.socket %1-tls.socket %1-tcp.socket %define libvirt_systemd_inet_posttrans() %libvirt_systemd_posttrans %1.service %1.socket %1-ro.socket %1-admin.socket %1-tls.socket %1-tcp.socket %define libvirt_systemd_inet_preun() %libvirt_systemd_preun %1.service %1.socket %1-ro.socket %1-admin.socket %1-tls.socket %1-tcp.socket # For daemons with only UNIX sockets and no unprivileged read-only access -%define libvirt_daemon_systemd_post_priv() %systemd_post %1.socket %1-admin.socket %1.service -%define libvirt_daemon_systemd_preun_priv() %systemd_preun %1.service %1-admin.socket %1.socket - %define libvirt_systemd_privileged_pre() %libvirt_systemd_reload_pre %1.service %1.socket %1-admin.socket %define libvirt_systemd_privileged_posttrans() %libvirt_systemd_posttrans %1.service %1.socket %1-admin.socket %define libvirt_systemd_privileged_preun() %libvirt_systemd_preun %1.service %1.socket %1-admin.socket -- 2.41.0

On Fri, Jul 14, 2023 at 04:39:34PM +0200, Andrea Bolognani wrote:
Plus some extras I'm throwing in for free :)
To understand why these changes are needed, see the original bug report[1] as well as the discussion triggered by Martin's initial attempt at addressing it[2].
Getting this right is quite tricky, so in order to convince myself that I'm not just going to break everyone's deployment I've tested things fairly extensively.
In particular, I've verified that things work as expected when upgrading from libvirt 9.0.0 (e.g. pre-split) on AlmaLinux 8 when the initial configuration is
* a default one (socket-activated monolithic daemon);
* monolithic daemon with --listen;
* modular daemons;
* modular daemons with virtproxyd-tcp.socket enabled;
as well as when installing from scratch with
* no particular configuration;
* local systemd preset overrides that result in the modular daemons being preferred to the monolithic one.
Everything seems to work fine, but further testing would certainly be more than welcome!
I don't have an objection to the conceptual approach. My concern is about where the solution is applied and divergance from Fedora guidelines. The long term direction of Fedora / RPM has been to reduce the number of scriptlets required to be explicitly listed in package specfiles, by having RPM globally apply script logic for all content in certain given directories. If we're using standard Fedora macros, then we'd not expect to see problems if the macros get changed to adapt to new approaches, but if we're going our own way all bets are off. The current macros we're using are specified in the Fedora packaging guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_syste... and their impl is provided by systemd upstream itself: https://github.com/systemd/systemd/blob/main/src/rpm/macros.systemd.in The problems described do not appear to be things unique to libvirt. IOW, I think the problem needs to be raised & addressed in context of the Fedora and systemd communities, rather than having libvirt diverge from normal Feora packaging practice. 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 Fri, Jul 14, 2023 at 04:02:30PM +0100, Daniel P. Berrangé wrote:
I don't have an objection to the conceptual approach.
My concern is about where the solution is applied and divergance from Fedora guidelines.
The long term direction of Fedora / RPM has been to reduce the number of scriptlets required to be explicitly listed in package specfiles, by having RPM globally apply script logic for all content in certain given directories. If we're using standard Fedora macros, then we'd not expect to see problems if the macros get changed to adapt to new approaches, but if we're going our own way all bets are off.
The current macros we're using are specified in the Fedora packaging guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_syste...
That's *mostly* correct, but as noted in one of the commit messages we have already been forced to implement a bunch of additional custom logic because the standard macros simply don't cover all the scenarios we need.
and their impl is provided by systemd upstream itself:
https://github.com/systemd/systemd/blob/main/src/rpm/macros.systemd.in
The problems described do not appear to be things unique to libvirt.
They're not! That said, somehow libvirt frequently manages to push boundaries in ways that are fairly uncomfortable :)
IOW, I think the problem needs to be raised & addressed in context of the Fedora and systemd communities, rather than having libvirt diverge from normal Feora packaging practice.
I absolutely agree with you, and I fully intend to push for these changes (or comparable ones) to be implemented in systemd, where they belong and from where they can benefit more than just us. That said, timing is a concern. Fedora 38 and RHEL 9.2 are both on libvirt 9.0.0 at the moment, so they haven't been hit by the issue yet, but new releases for both are just around the corner and I have little confidence that we'd be able to push the necessary changes through in time. So a local solution seems like the only plausible way that we can avoid breaking user's deployments. -- Andrea Bolognani / Red Hat / Virtualization

On Fri, Jul 14, 2023 at 08:25:57AM -0700, Andrea Bolognani wrote:
On Fri, Jul 14, 2023 at 04:02:30PM +0100, Daniel P. Berrangé wrote:
I don't have an objection to the conceptual approach.
My concern is about where the solution is applied and divergance from Fedora guidelines.
The long term direction of Fedora / RPM has been to reduce the number of scriptlets required to be explicitly listed in package specfiles, by having RPM globally apply script logic for all content in certain given directories. If we're using standard Fedora macros, then we'd not expect to see problems if the macros get changed to adapt to new approaches, but if we're going our own way all bets are off.
The current macros we're using are specified in the Fedora packaging guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_syste...
That's *mostly* correct, but as noted in one of the commit messages we have already been forced to implement a bunch of additional custom logic because the standard macros simply don't cover all the scenarios we need.
and their impl is provided by systemd upstream itself:
https://github.com/systemd/systemd/blob/main/src/rpm/macros.systemd.in
The problems described do not appear to be things unique to libvirt.
They're not! That said, somehow libvirt frequently manages to push boundaries in ways that are fairly uncomfortable :)
IOW, I think the problem needs to be raised & addressed in context of the Fedora and systemd communities, rather than having libvirt diverge from normal Feora packaging practice.
I absolutely agree with you, and I fully intend to push for these changes (or comparable ones) to be implemented in systemd, where they belong and from where they can benefit more than just us.
That said, timing is a concern. Fedora 38 and RHEL 9.2 are both on libvirt 9.0.0 at the moment, so they haven't been hit by the issue yet, but new releases for both are just around the corner and I have little confidence that we'd be able to push the necessary changes through in time. So a local solution seems like the only plausible way that we can avoid breaking user's deployments.
If we at least start the discussion, we can get feedback on whether the idea is likely to gain traction, or there are other things we have overlooked 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 Fri, Jul 14, 2023 at 04:28:11PM +0100, Daniel P. Berrangé wrote:
IOW, I think the problem needs to be raised & addressed in context of the Fedora and systemd communities, rather than having libvirt diverge from normal Feora packaging practice.
I absolutely agree with you, and I fully intend to push for these changes (or comparable ones) to be implemented in systemd, where they belong and from where they can benefit more than just us.
That said, timing is a concern. Fedora 38 and RHEL 9.2 are both on libvirt 9.0.0 at the moment, so they haven't been hit by the issue yet, but new releases for both are just around the corner and I have little confidence that we'd be able to push the necessary changes through in time. So a local solution seems like the only plausible way that we can avoid breaking user's deployments.
If we at least start the discussion, we can get feedback on whether the idea is likely to gain traction, or there are other things we have overlooked
I can open an issue on the systemd side pointing to these patches, but polishing things up to the level of a proper PR is off the table right now because I simply can't allocate enough time for it. Would you consider that good enough to move forward with the libvirt changes? On the Fedora side, I wouldn't know what forum would be the most appropriate to get the discussion started. Any pointers? -- Andrea Bolognani / Red Hat / Virtualization

On Fri, Jul 14, 2023 at 08:52:15AM -0700, Andrea Bolognani wrote:
On Fri, Jul 14, 2023 at 04:28:11PM +0100, Daniel P. Berrangé wrote:
IOW, I think the problem needs to be raised & addressed in context of the Fedora and systemd communities, rather than having libvirt diverge from normal Feora packaging practice.
I absolutely agree with you, and I fully intend to push for these changes (or comparable ones) to be implemented in systemd, where they belong and from where they can benefit more than just us.
That said, timing is a concern. Fedora 38 and RHEL 9.2 are both on libvirt 9.0.0 at the moment, so they haven't been hit by the issue yet, but new releases for both are just around the corner and I have little confidence that we'd be able to push the necessary changes through in time. So a local solution seems like the only plausible way that we can avoid breaking user's deployments.
If we at least start the discussion, we can get feedback on whether the idea is likely to gain traction, or there are other things we have overlooked
I can open an issue on the systemd side pointing to these patches, but polishing things up to the level of a proper PR is off the table right now because I simply can't allocate enough time for it. Would you consider that good enough to move forward with the libvirt changes?
On the Fedora side, I wouldn't know what forum would be the most appropriate to get the discussion started. Any pointers?
Fedora devel list is probably the catch all place to raise it https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/ There is a packaging list, which is technically the most on-topic place, but it is mostly a ghost town as people tend to use the devel list for everything https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.... 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 Fri, Jul 14, 2023 at 05:20:16PM +0100, Daniel P. Berrangé wrote:
If we at least start the discussion, we can get feedback on whether the idea is likely to gain traction, or there are other things we have overlooked
I can open an issue on the systemd side pointing to these patches, but polishing things up to the level of a proper PR is off the table right now because I simply can't allocate enough time for it. Would you consider that good enough to move forward with the libvirt changes?
On the Fedora side, I wouldn't know what forum would be the most appropriate to get the discussion started. Any pointers?
Fedora devel list is probably the catch all place to raise it
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/
Done. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... -- Andrea Bolognani / Red Hat / Virtualization

On Thu, Jul 20, 2023 at 07:42:19AM -0700, Andrea Bolognani wrote:
On Fri, Jul 14, 2023 at 05:20:16PM +0100, Daniel P. Berrangé wrote:
If we at least start the discussion, we can get feedback on whether the idea is likely to gain traction, or there are other things we have overlooked
I can open an issue on the systemd side pointing to these patches, but polishing things up to the level of a proper PR is off the table right now because I simply can't allocate enough time for it. Would you consider that good enough to move forward with the libvirt changes?
On the Fedora side, I wouldn't know what forum would be the most appropriate to get the discussion started. Any pointers?
Fedora devel list is probably the catch all place to raise it
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/
Done.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
Summing up the discussion that happened in that thread over the last week: * while the proper way to address the issue at hand is to change or replace the macros shipped with systemd; * given that such a process would require more time than we have available before Fedora and RHEL users are affected; * there is no strong objection to libvirt adopting the solution that I've implemented as a temporary measure. Based on the above and the fact that the series is now fully ACKed, I will push it before the end of the day so that it can be part of rc2. Please shout if you have a problem with this plan! -- Andrea Bolognani / Red Hat / Virtualization
participants (3)
-
Andrea Bolognani
-
Daniel P. Berrangé
-
Martin Kletzander