Re: [Qemu-devel] [PATCH 1/4] qapi: Support features for structs

[Peter Krempa <pkrempa@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3968 bytes --]

On Wed, May 15, 2019 at 15:48:29 +0200, Markus Armbruster wrote:
> Kevin Wolf <kwolf@redhat.com> writes:
> > Am 18.04.2019 um 22:03 hat Markus Armbruster geschrieben:
> >> Kevin Wolf <kwolf@redhat.com> writes:

[...]

> > Do you expect libvirt to check a full list of all QMP commands, types,
> > etc. it ever uses against the schema after starting a VM or something
> > like that?
> 
> I'm merely responding to demand.
> 
> Subject: Minutes of KVM Forum BoF on deprecating stuff
> Message-ID: <87mur0ls8o.fsf@dusky.pond.sub.org>
> 
> * We need to communicate "you're using something that is deprecated".
>   How?  Right now, we print a deprecation message.  Okay when humans use
>   QEMU directly in a shell.  However, when QEMU sits at the bottom of a
>   software stack, the message will likely end up in a log file that is
>   effectively write-only.
>  
>   - The one way to get people read log files is crashing their
>     application.  A command line option --future could make QEMU crash
>     right after printing a deprecation message.  This could help with
>     finding use of deprecated features in a testing environment.
> 
>   - A less destructive way to grab people's attention is to make things
>     run really, really slow: have QEMU go to sleep for a while after
>     printing a deprecation message.
>     
>   - We can also pass the buck to the next layer up: emit a QMP event.
> 
>     Sadly, by the time the next layer connects to QMP, plenty of stuff
>     already happened.  We'd have to buffer deprecation events somehow.
> 
>     What would libvirt do with such an event?  Log it, taint the domain,
>     emit a (libvirt) event to pass it on to the next layer up.
> 
>   - A completely different idea is to have a configuratin linter.  To
>     support doing this at the libvirt level, QEMU could expose "is
>     deprecated" in interface introspection.  Feels feasible for QMP,
>     where we already have sufficiently expressive introspection.  For
>     CLI, we'd first have to provide that (but we want that anyway).

From all of the above, the most important bit is still that the libvirt
developers at first identify sooner rather than later that something is
deprecated. That way we can either make sure to not use it any longer if
there's a compatible replacement or perhaps add the aforementioned
linter to print a warning that the config may not be supported in some
time.

The linter will still require us seeing what is deprecated, so marking
that in the schema is useful. There are two dimensions to this though.
QMP is the first, where introspection is awesome. Then there is command
line and it's various commands which don't have QMP counterparts and
that doesn't work that well there.

In normal operation there's not much we can do here as refusing to use
deprecated attributes or commands would cause regressions. In the test
suite we are already validating the output of some of our tests against
the QMP schema so making those fail when they are deprecated is
certainly possible but not very likely to ever catch something as our
QMP tests are exremely basic.

It would be much more potent to have something like this to allow
validating the command line automatically, but this would require using
some structured format first. Without that it's really up to us
implementing a check for every unsupported feature as we figure out it's
deprecated rather than having it done automatically.

Things got way better after we got CC'd on the deprecation document,
since we can make sure that we don't use the particular removed thing.

There are still a few things that are not addressed which were present
before this was happening. E.g. we don't specify the full NUMA topology
on the commandline and get an angry message back on the command line.
This is going on for almost a year now and nobody complained. Stderr
messages are ineffective.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]