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
