[libvirt PATCH 6/8] rpm: Introduce new macros for handling of systemd units

[Martin Kletzander]

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 at redhat.com>

Reviewed-by: Martin Kletzander <mkletzan at redhat.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20230725/5887389e/attachment.sig>