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

[Jiri Denemark]

On Fri, Oct 05, 2018 at 12:10:51 +0100, Daniel P. Berrangé wrote:
> On Fri, Oct 05, 2018 at 12:33:57PM +0200, Jiri Denemark wrote:
> > 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.
> 
> If some user visible feature is actually removed, then our hand is
> forced - we have to pick something else to replace it. This is what
> happened with the default NIC with RHEL stopped building rtl8139,
> so we had to have a default fallback.
> 
> That change is/was not seemless since there exist OS which supported
> rtl8139 but which lacked e1000 / virtio-net drivers. Fortunately apps
> already use libosinfo to explicitly set NIC model so the breakage was
> not so visible.
> 
> If 'i440fx' is ever actually deleted we would have todo something
> similar - prefer i440fx for best historical compat, but fallback
> to q35 despite knowing it could break.

We already do so. If QEMU supports "pc", we use that as the default (and
resolve it to some pc-i440fx-* machine type), otherwise we use whatever
QEMU says is the default.

My point is whether we should wait until we're forced or switch the
default once it's deprecated to make sure newly created domains get the
new default early and they will keep working once the old default is
removed.

Of course, changes to the XML or guest configuration may be needed for
the new default to actually work, but I think it's better to do the
changes when creating new domains rather than realizing that suddenly
all my existing domains won't boot anymore because the default value
they got when I created them was removed.

Jirka