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

[Markus Armbruster]

Peter Krempa <address@hidden> writes:

> On Wed, May 15, 2019 at 15:48:29 +0200, Markus Armbruster wrote:
>> Kevin Wolf <address@hidden> writes:
>> > Am 18.04.2019 um 22:03 hat Markus Armbruster geschrieben:
>> >> Kevin Wolf <address@hidden> 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: <address@hidden>
>> 
>> * 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.

Yes, that's the goal.  The above lists the ideas we had on how to get
closer to the goal.

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

You're asking for command line QAPIfication.

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

I figure they work as well as anything when a human runs QEMU directly.

They're ineffective when a management application runs QEMU.  It won't
be able to make sense of deprecation messages it doesn't already know
(and therefore doesn't actually need), so all it can do is bury them in
logs nobody reads until after things have gone south.

Exposing deprecation in introspection is just one idea of several.  It
might be the least immediately useful one.  We'll likely want to
do more.