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 :|
