On 6/16/23 02:12, Martin Kletzander wrote:
On Wed, Jun 14, 2023 at 04:45:06PM -0600, Jim Fehlig wrote:
On 6/9/23 03:05, Andrea Bolognani wrote:
On Thu, Jun 08, 2023 at 12:35:45PM -0600, Jim Fehlig wrote:
On 6/8/23 08:52, Andrea Bolognani wrote:
On Wed, Jun 07, 2023 at 04:31:36PM +0200, Martin Kletzander wrote:
+# Since this was split into a different package, a transparent update for
the
+# virtproxyd units could actually disable an already configured ones
+# (e.g. virtproxyd-tls.socket) as %systemd_post runs `systemctl preset`
if this
+# is an installation (and is skipped on update). So skip this step for
those
+# that need an extra setup to work since they will most likely not be
preset to
+# enabled, but that is up to the point of the distribution.
+%libvirt_daemon_systemd_post virtproxyd
It's actually worse than that: if you are using the monolithic daemon
on a distro that uses split daemons by default (e.g. Fedora),
Why use the monolithic and split daemons together? Shouldn't we discourage
such configuration? :-)
Whether to use monlithic or split daemons is ultimately a choice of
the local admin. Fedora defaults to split daemons, but switching back
to a "classic" monolithic deployment is still a fully supported
scenario.
Additionally, the current default has been adopted relatively
recently, and we have made the explicit decision *not* to migrate
existing installations over. So if your OS was originally installed
before split daemons had become the default and you've been dutifully
upgrading to subsequent Fedora releases without ever reinstalling,
then you're also going to be using the monolithic daemon.
Basically we need to detect if we're installing the
libvirt-daemon-proxy package as part of an upgrade and *not touch
anything* if that's the case. I'm not sure how that can be achieved
in the context of RPM scriptlets though, or if it's even possible :(
It's possible to determine a package install vs upgrade, but IIUC the
problem can occur when installing or upgrading libvirt-daemon-proxy. The
usual 'if [ $1 -ge 2 ]' for upgrade-only actions wont work in that case.
Yeah, exactly: it's easy to detect whether a single package is being
upgraded or installed from scratch, but in this case we would need to
know whether libvirt-daemon is being upgraded in the scriptlet for
libvirt-daemon-proxy, which I don't think is possible.
I think we need to know more than whether libvirt-daemon is being upgraded. We
need to also know whether it's running, right? Even if libvirt-daemon is being
upgraded, it's fine to call %systemd_post on virtproxyd sockets if the libvirtd
ones are disabled, right? If this is the case, my idea to use trigger scriptlets
doesn't help.
Can we somehow enforce that libvirt-daemon is fully configured before
libvirt-daemon-proxy? If so, we could create a witness file based on
the information we need in libvirt-daemon's %post, look at it in
libvirt-daemon-proxy's %post and base our decision on that.
What would the witness file indicate? As I understand, it would essentially have
to indicate whether libvirtd sockets/service are enabled. If so, couldn't that
be done directly in virtproxy post script? Something like the below hack?
We already have some things for this. There is
libvirt_daemon_schedule_restart, but that is done in the post phase.
What we could do is check the current state (whether libvirtd is running
and what is being installed) in %pretrans of the daemon and virtproxyd,
save it somewhere similar to libvirt_daemon_schedule_restart and then in
%posttrans or %post actually figure out what the new state should be.
Does that make sense?
Yes, and sorry for getting caught up in the followup issue Andrea raised.
Although I'm having a hard time reproducing either issue, which makes it
difficult to experiment and eventually test a fix.
My setup is a recent openSUSE Tumbleweed. For your issue I added the following
presets to /usr/lib/systemd/system-preset/90-default-openSUSE.preset
enable virtqemud.socket
enable virtlogd.socket
enable virtnetworkd.socket
enable virtnodedevd.socket
enable virtstoraged.socket
enable virtsecretd.socket
Next I installed libvirt-daemon and libvirt-daemon-qemu without commit
b1da03b5b3. As expected, all the above sockets where enabled, while
virtproxyd.socket and libvirtd.socket were disabled. I then enabled
virtproxyd.socket and virtproxyd-tcp.socket. Finally I updated the setup with
packages containing b1da03b5b3, the new libvirt-daemon-proxy was installed, but
in the end virtproxyd.socket and virtproxyd-tcp.socket were still enabled and
the system seemed fine.
In an attempt to reproduce Andrea's report, I added the following presets to
/usr/lib/systemd/system-preset/90-default-openSUSE.preset
enable virtqemud.socket
enable virtlogd.socket
enable virtnetworkd.socket
enable virtnodedevd.socket
enable virtstoraged.socket
enable virtsecretd.socket
enable virtproxyd.socket
As before, installed packages without commit b1da03b5b3. I then disabled all the
virt* presets (with exception of virtlogd) and enabled libvirtd.socket. After
updating to packages containing commit b1da03b5b3, virtproxyd.socket was still
disabled and libvirt.socket was enabled. No problem connecting to libvirtd, even
after the service timeout.
IIUC, the Tumbleweed default is to disable presets, similar to the Fedora
default you mentioned earlier. The systemd-presets-common-SUSE package contains
/usr/lib/systemd/system-preset/99-default-disable.preset, which has the single
entry 'disable *'.
Any tips on reproducing the issue? I must be missing something. What are the
libvirt-related presets in Fedora? I couldn't easily find them. FYI, the
Tumbleweed ones are here
https://build.opensuse.org/package/show/Base:System/systemd-presets-common-SUSE
https://build.opensuse.org/package/show/Base:System/systemd-presets-branding-openSUSE
In the past I've never added libvirt services/sockets to the openSUSE presets
since users could easily enable libvirtd and virtlogd and be done with it. (Note
the SLES presets do enable libvirtd and virtlogd.) But it becomes more
burdensome with modular daemons, so I plan to add the above presets (excluding
virtproxyd) to the openSUSE defaults.
Regards,
Jim
