On Wed, Jan 11, 2023 at 09:24:09AM -0800, Andrea Bolognani wrote:
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?
Yes, the virtlockd one is a bit inconsistent. Since we don't have it enabled by default, we don't need it as a Requires clause either.
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.
We need to fix the Fedora presets, since I notice we missed the virtlockd.socket / virtlogd.socket presets. This was harmless while a Requires existed. If we fix the presets, we can drop the virtlockd requires. 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 :|