Re: [Qemu-devel] [libvirt] [PULL 25/26] block: Remove deprecated -drive option serial

[Cornelia Huck <cohuck@redhat.com>]

On Tue, 10 Jul 2018 16:39:31 +0200
Peter Krempa <pkrempa@redhat.com> wrote:

> On Tue, Jul 10, 2018 at 16:22:08 +0200, Cornelia Huck wrote:
> > On Tue, 10 Jul 2018 07:59:15 +0200
> > Markus Armbruster <armbru@redhat.com> wrote:
> >   
> > > In addition to actively pulling libvirt developers into review of
> > > deprecation patches, we should pursue the idea to optionally let QEMU
> > > fail on use of deprecated features, then have libvirt run its test suite
> > > that way.  
> > 
> > What about the following:
> > 
> > qemu_deprecated_option("old_option", "modern_option");  
> 
> I think this is too simplified. You can deprecate only a certain value
> for an option or even just a combination of values and options. The
> check will need to be programatic and error reporting probably can't be
> reasonably machine readable anyways.

Kevin's suggestion of using a simple message instead of this old/modern
option thing is actually better (and would cover more). My intention
behind printing a message (somewhere) was to make this friendly to
command line users as well.

> 
> > Which would then print (in normal operation)
> > 
> > "WARNING: 'old_option' is deprecated and will be removed; use 'modern_option' instead"
> > 
> > to the monitor (or to stderr? to both?).
> > 
> > If you start QEMU with a -no-deprecated-options switch, it would print
> > 
> > "ERROR: 'old_option' is deprecated and will be removed; use 'modern_option' instead"
> > 
> > and do an exit(1).
> > 
> > Would that be workable?  
> 
> For delivering the warnings via monitor you'll need a store that will
> collect all the warnings and prepare them for delivery. You've got
> basically two options:
> 
> 1) monitor command to poll for deprecated options
> 2) event with deprecated options
> 
> Both require storing them since libvirt connects to the monitor only
> after the command line is processed.
> 
> Warnings printed to stderr are nearly useless because until something
> breaks nobody bothers to read the log files.

So, from that I gather that a hard failure would be the easiest for
libvirt to detect (and everything else would become complicated really
quickly), right?

If we fail with exit(1), can libvirt check any message that is logged
right before that?

> 
> To make any reasonable use of -no-deprecated-options we'd also need
> something that simulates qemu startup (no resources are touched in fact)
> so that we can run it against the testsuite. Otherwise the use will be
> limited to developers using it with the configuration they are
> currently testing.

Would that moan loudly that you should poke the libvirt developers if
some kind of testsuite failure is detected? Or am I misunderstanding?

Who is, in general, testing which libvirt version? I can think of:
- libvirt developers, which will probably run libvirt current git, but
  more likely a released QEMU?
- QEMU (and other related tools) developers, who will probably use QEMU
  current git, but a released libvirt
- normal (technical) users and (integration) testers, who will probably
  use released versions of libvirt and QEMU