Re: [libvirt] [Qemu-devel] [PATCH 2/2] qapi: deprecate implicit filters
Peter Krempa <pkrempa(a)redhat.com> writes:
On Thu, Aug 15, 2019 at 12:49:28 +0200, Kevin Wolf wrote:
> Am 14.08.2019 um 21:27 hat John Snow geschrieben:
[...]
> > example:
> >
> > { "return": {},
> > "deprecated": True,
> > "warning": "Omitting filter-node-name parameter is deprecated,
it will
> > be required in the future"
> > }
> >
> > There's no "error" key, so this should be recognized as success
by
> > compatible clients, but they'll definitely see the extra information.
> >
> > Part of my motivation is to facilitate a more aggressive deprecation of
> > legacy features by ensuring that we are able to rigorously notify users
> > through any means that they need to adjust their scripts.
>
> Who would read this, though? In the best case it ends up deep in a
> libvirt log that nobody will look at because there was no error. In the
> more common case, the debug level is configured so that QMP traffic
> isn't even logged.
The best we could do here is to log a warning. Thankfully we have one
central function which always checks the returned JSON from qemu so we
could do that universally.
The would end up in the system log and alternatively also in the VM
log file. I agree with Kevin that the possibility of it being noticed
is rather small.
From my experience users report non-fatal messages mostly only if it is
spamming the system log. One of instances are very unlikely to be
noticed.
In my experience it's better to notify us in libvirt of such change and
we will try our best to fix it.
How to best alert the layers above QEMU was one of the topic of the KVM
Forum 2018 BoF on deprecating stuff. Minutes:
Message-ID: <87mur0ls8o.fsf(a)dusky.pond.sub.org>
https://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg05828.html
Relevant part:
* 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).
- We might also want to dispay deprecation messages in QEMU's GUI
somehow, or on serial consoles.