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

[Daniel P. Berrangé]

On Fri, Oct 05, 2018 at 10:34:33AM +0200, Jiri Denemark wrote:
> On Thu, Oct 04, 2018 at 14:13:41 +0100, Daniel P. Berrangé wrote:
> > The problem with saying applications were doing it "wrong" is that
> > this definition of "wrong" changes. Applications were perfectly
> > justified in not providing a machine type, because the concept
> > didn't even exist in earlier libvirt. Once it did exist, we still
> > only supported x86, and there was no q35, so it was still valid to
> > not specify it.
> > 
> > Even today it is reasonable to not care about machine type in case
> > where the app only cares about x86.
> > 
> > Our view of "best" way to configure a guest is changing and in many
> > cases it is becoming increasingly clear that there's no single
> > "best" way, or no single perfect default.
> 
> As I tried to explain in another mail in this thread, I definitely agree
> we should not change defaults just because we think some value is better
> now. That's really a job for libosinfo.
> 
> 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.

It is not the kind of think an application will dynamically take
action on at runtime. It is something application developers need
to be told about so they can adapt future code releases as needed.

> So taking "q35" as an example, if QEMU marks i440fx machine types as
> deprecated (they seem to be thinking about it) I don't see that big
> difference[*] in changing the default machine type to "q35". After all
> we will automatically change the default once i440fx is removed
> completely.

There's no active plans to deprecate or remove i440fx upstream in
QEMU.  If a downstream did remove it, then clearly that'll impose
some level of pain on applications.

This is something where better documentation would help application
developers. We report on supported machine types in capabilities
XML but few applications do anything useful with this. We're also
intending to add support to libosinfo to report on machine type
compatibility for OS.

We've got nothing that explains to applications how all this
functionality fits together, nor good description of application
relevant differences between i440fx & q35. So it is not surprising
that code apps have around machine types is very sub-par and liable
to break. 

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