Re: [PATCH V7 09/12] spec: Remove libvirt-daemon dependency from drivers
On Wed, Jan 11, 2023 at 04:42:49PM +0000, Daniel P. Berrangé wrote:
On Wed, Jan 11, 2023 at 08:24:08AM -0800, Andrea Bolognani wrote:
> I think we might need to weaken these relationship from Requires to
> Wants, as that should still ensure that the corresponding sockets are
> activated for standard deployments without making more specialized
> ones (e.g. without virtlockd) impossible.
Weakening it to Wants means that virtqemud will still startup even
if virtlogd fails to start. This is bogus because any attempt jto
start a guest will then fail due to inability to connect to
virtlogd's socket.
Users trying to run in non-standard configurations can put in a
systemd unit file override. They already need to edit the virtqemud
configuration, so editting the unit file to match isn't a terrible
burden.
I'm thinking of KubeVirt, which is the scenario I'm most familiar
with, and in that case virtlogd is used but virtlockd isn't.
Adding an override to remove the Requires=virtlockd.socket would
indeed not be a big deal, but if we keep the relationships as they
are then the libvirt-daemon-driver-qemu package needs to depend on
the libvirt-daemon-driver-lock to keep it functional. So KubeVirt
will not be able to avoid installing virtlockd despite not using it.
The ironic part is that libvirt-daemon-driver-qemu doesn't depend on
libvirt-daemon-plugin-lockd, so you will have virtlockd ready to go
even while potentially missing the corresponding plugin! And, even
better, also when you have configured storage locking, but have
chosen the sanlock backend instead of the virtlockd one!
Based on the fact that virtlogd is opt-out and virtlockd is opt-in,
can we leave the Requires=virtlogd.socket relationship alone and add
a dependency on libvirt-daemon-log to libvirt-daemon-driver-qemu,
while at the same time demoting the Requires=virtlockd.socket to a
Want and *not* adding a dependency on libvirt-daemon-lock?
> Similarly, I think we're missing Wants for
virtstoraged.socket,
> virtnetworkd.socket, virtsecretd.socket and so on.
We didn't bother with those since it is harmless either way. The
distro unit file presets will configure those sockets to be started
on boot if modular daemons are desired. If a user overrides this
that's fine, we'll just fail to start a guest that has a config
setting that requires them.
The same can be said of virtlockd. So I think we should either add
all the missing Want relationships, or drop the one for virtlockd.
--
Andrea Bolognani / Red Hat / Virtualization