[libvirt] [RFC 0/7] Warn at runtime when deprecated features are used

Daniel P. Berrangé berrange at redhat.com
Fri Oct 5 11:05:21 UTC 2018


On Fri, Oct 05, 2018 at 11:38:14AM +0200, Andrea Bolognani wrote:
> On Fri, 2018-10-05 at 09:54 +0100, Daniel P. Berrangé wrote:
> > On Fri, Oct 05, 2018 at 10:34:33AM +0200, Jiri Denemark wrote:
> > > But what if QEMU (or any other hypervisor) marks something (device
> > > model, machine type) as deprecated and we use that deprecated value as
> > > our default. Shouldn't we be able to tell about it to our users (here
> > > runtime warnings could help) when they use such thing explicitly and
> > > choose a different default value? That would help users with the
> > > transition and once hypervisor drops support for it completely, fewer
> > > existing domains will be affected since the recently created ones would
> > > already use non-deprecated defaults.
> > 
> > QEMU already emits warnings on stderr whenever something that is
> > deprecated is used, and those end up in the libvirt log file for
> > that guest. I don't think that we need to duplicate what QEMU
> > is already reporting again.
> 
> Warnings printed on stderr -> users and developers will actually
> see them, be annoyed by them, eventually cave in and act upon them.
> 
> Warnings written to a log -> nobody will notice them, until one day
> things suddenly stop working apparently out of the blue.
> 
> We might pretend that's not the case, but really, it is.

Unless you're talking about a CLI tool (virt-install, virsh), there
is no difference between those two scenarios. For virt-manager,
virt-viewer, oVirt, OpenStack, KubeVirt, stderr is never going to
be seen, it just ends up in a log file. So I don't find that
distinction to be compelling.

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




More information about the libvir-list mailing list