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

[Peter Krempa]

On Tue, Jul 10, 2018 at 17:01:22 +0200, Cornelia Huck wrote:
> On Tue, 10 Jul 2018 16:39:31 +0200
> Peter Krempa <pkrempa at 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 at redhat.com> wrote:

[...]

> > > "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?

People start complaining only when stuff breaks. If anything is optional
people will usually not enable it. That makes any non-mandatory option
not work in most cases.

Since we are talking about deprecation we can't really make any of this
default though so there will always be a level of user interaction
required.

An option is to do a automatic testing where one of this approaches will
be enabled. For that you need a way to generate configurations which
libvirt would use in real life. We have a rather big collection of XMLs
which describe a valid configuration but the problem with using them on
a real qemu is that most of the disk paths/network targets/other
resources are made up and making them work with a real qemu would range
from being painful to being impossible.

If we start from scratch you then lack coverage.

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

Yes we currently use this for very early failures which occur prior to
the monitor working.

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

Generally it should make somebody complain. But there is a problem.
Since we are talking deprecation it can't be enabled by default. And by
not making it default most of the users will not enable that option.

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

Speaking for myself I run git+patches libvirt and git version of
qemu as I'm usually working with new features. (sometimes git+patches
qemu if it's a bleeding edge feature or fix for a feature)

> - QEMU (and other related tools) developers, who will probably use QEMU
>   current git, but a released libvirt

This is probably generally true.

> - normal (technical) users and (integration) testers, who will probably
>   use released versions of libvirt and QEMU

This too
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180710/f0478602/attachment-0001.sig>