Re: [Qemu-devel] [PATCH 2/2] qapi: deprecate implicit filters - Vladimir Sementsov-Ogievskiy

From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: Markus Armbruster <armbru@redhat.com>, Kevin Wolf <kwolf@redhat.com>
Cc: Denis Lunev <den@virtuozzo.com>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
	"libvir-list@redhat.com" <libvir-list@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"mreitz@redhat.com" <mreitz@redhat.com>,
	John Snow <jsnow@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 2/2] qapi: deprecate implicit filters
Date: Fri, 16 Aug 2019 12:58:00 +0000	[thread overview]
Message-ID: <99135eb2-5a37-32a3-090c-3c50d8730bb6@virtuozzo.com> (raw)
In-Reply-To: <87d0h5p9wp.fsf@dusky.pond.sub.org>

16.08.2019 15:33, Markus Armbruster wrote:
> Kevin Wolf <kwolf@redhat.com> writes:
> 
>> Am 15.08.2019 um 21:24 hat Markus Armbruster geschrieben:
> [...]
>>> Let's assume all libvirt ever does with deprecation notices is logging
>>> them.  Would that solve the problem of reliably alerting libvirt
>>> developers to deprecation issues?  Nope.  But it could help
>>> occasionally.
>>
>> I'm not saying that deprecation notices would hurt, just that they
>> probably won't solve problem alone.
> 
> No argument.
> 
>> Crashing if --future is given and logging otherwise seems reasonable
>> enough to me. Whether we need to wire up a new deprecation mechanism in
>> QMP for the logging or if we can just keep printing to stderr is
>> debatable. stderr already ends up in a log file, a QMP extension would
>> require new libvirt code. If libvirt would log deprecation notices more
>> prominently, or use the information for tainting or any other kind of
>> processing, a dedicated QMP mechanism could be justified.
> 
> I'd like to start with two tasks:
> 
> * A CLI option to configure what to do on use of a deprecated feature.
> 
>    We currently warn.  We want to be able to crash instead.  Silencing
>    the warnings might be useful.  Turning them into errors might be
>    useful.
> 
>    The existing ad hoc warnings need to be replaced by a call of a common
>    function that implements the configurable behavior.
> 
> * QAPI feature flag "deprecated", for introspectable deprecation, and
>    without ad hoc code.
> 
> Then see whether our users need more.
> 

Crashing is useful for libvirt developers, it's obvious, just enable crash-on-deprecated
on all testing environments and most probably we will not miss such a case.

For qapi I doubt is it really needed. Implementing code in libvirt which will check for command
(or it's parameter, or it's parameter "optionality" is deprecated) ? It's hard and what libvirt
should report to final user? It becomes a kind of synthetic error in libvirt code, like

...
log_error("We are going to divide by zero. It's a bug, please report it to developers!");
x = a / 0;
...

It's simpler to fix second line than implement special mechanism including protocol specification
to report such a case.

I exaggerate of course with this example, but I doubt that implementing a special protocol
for it worth doing. And I think notifying libvirt by email (as Peter said) and providing option
"crash-on-deprecated" in Qemu are enough for libvirt developers to prevent and to fix using
deprecated things.

In other words, I don't see why reporting deprecated feature usage is better in libvirt than in
Qemu (by warning, error or crash), and in Qemu it's much more simple and don't need QAPI protocol
extension.

(I'm sorry if I'm repeating already written arguments, I've not read the whole thread)

-- 
Best regards,
Vladimir