[PATCH V7 09/12] spec: Remove libvirt-daemon dependency from drivers

[Daniel P. Berrangé]

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