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

[Jiri Denemark]

On Fri, Oct 05, 2018 at 09:54:02 +0100, Daniel P. Berrangé wrote:
> 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.

OK, but if it's us choosing some default which QEMU considers
deprecated, it's us who should dealt with it. That is, change the
default IMHO. Sure apps could just stop relying on defaults and choose
something specific which is not deprecated, but that doesn't mean we as
a user of QEMU should continue using default values which got deprecated
and are likely to be removed.

If it's something which is not user/guest visible, we are already trying
to move to more modern interfaces. That is easy since it doesn't change
anything for libvirt users, but I feel like we need to have a plan for
stuff which actually is visible to our users.

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

I wasn't talking about downstream and I probably gave a wrong example
and mixed several different things, but the point stays valid. We should
have some sort of a policy when and how we change default values rather
than saying "we never do that except when we already did so". One of the
reason why we store chosen defaults in domain XML is to be able to
change the defaults without breaking existing domains. We should
formally touch this area in our "Support guarantees" document
(https://libvirt.org/support.html) so that users/apps know what they can
expect and we don't have to think or fight everytime someone comes up
with an idea to change a default value.

Jirka