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

[Jiri Denemark]

On Tue, Oct 02, 2018 at 18:26:12 +0200, Andrea Bolognani wrote:
> On Tue, 2018-10-02 at 17:19 +0200, Peter Krempa wrote:
> > Our documentation states in multiple places that fields not populated by
> > the user are mostly hypervisor dependant what the default will become.
> > 
> > In my opinion the machine type is similarly hypervisor dependant, and in
> > this case the "hypervisor" for the libvirt-qemu infrastructure also
> > involves libvirt's qemu driver.
> 
> I don't necessarily disagree with you, but it should be noted that
> attempts to change libvirt's own defaults have been rejected times
> and times again on the basis that existing applications were, despite
> that being a very bad idea, relying on them.

I'm going to talk only about default values which are stored in domain
XML once chosen here as the ones which do not make it into the XML are
much more complicated and we can't easily change them...

I think rejecting changes to libvirt's defaults in general is wrong. The
defaults are not stable and have never been and we should stop
pretending they are. When we select a default value for something we
store it in the domain XML to protect us from future changes to the
default value. Not to mention that defaults may depend on hypervisor
version and we need to make sure we fail to start a domain on newer
hypervisor with different defaults rather than silently starting a
domain with different devices and hope for not breaking the guest OS.

So for example, when a domain XML contains no machine type or even just
an alias, such as "pc", we replace it with something real when the
domain is defined. Thus when the exact same domain XML will result in
different machine type depending on the QEMU version. Of course, the
difference is not so drastic as in "pc" vs. "q35", but the difference is
real.

That said, I'm not saying we should just change our defaults just
because we think a new value is better. We have have libosinfo for
telling users what values are the best for their guest OS. But in case
QEMU deprecates some device model or even machine type, I think we
should avoid using the deprecated model as a default value to prepare
people for transition. Once the deprecated model is removed, our default
would change anyway, but existing domain would suddenly start to fail in
case we did not change the default when the model was marked as
deprecated.

Of course, this would not help apps or users using transient domains
without default values, but such apps/users are just broken if they rely
on defaults. For persistent domains libvirt takes care of preserving
default values from when a domain was first defined. Users/apps have to
handle this themselves for transient apps if they care. Libvirt updates
the live XML and they can read it and update their definition to make
the defaults persistent. There's nothing more we can do for them and I
don't think this should block us from changing any defaults. We're
already doing so anyway.

Jirka