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

[Markus Armbruster]

Peter Krempa <address@hidden> writes:

> On Thu, Jul 12, 2018 at 08:38:25 +0200, Markus Armbruster wrote:
>> Kevin Wolf <address@hidden> writes:
>> > Am 10.07.2018 um 16:22 hat Cornelia Huck geschrieben:
>> >> On Tue, 10 Jul 2018 07:59:15 +0200
>> >> Markus Armbruster <address@hidden> wrote:
>> >> Would that be workable?
>> >
>> > I think the function should just take a message:
>> >
>> >     /* Works like error_report(), except for the WARNING/ERROR prefix
>> >      * and exit(1) if -no-deprecated-options is set */
>> >     void deprecation_report(const char *fmt, ...);
>> 
>> I like it.  The contract could use a bit of polish, but that's detail.
>> 
>> > We don't necessarily deprecate only options, but we might also deprecate
>> > monitor commands, specific options values (while keeping other values of
>> > the same option) etc.
>> 
>> Exactly.
>
> For monitor commands we luckily have QMP introspection which can help a
> lot in this case. At least for deprecating stuff that is expressable by
> the schema.

Introspection doesn't convey "deprecated", but...

> In libvirt we are actually doing schema validation of the blockdev-add
> arguments generators and most commands which are covered by the
> qemumonitorjsontest. The schema used is based on our capability
> detection so it's gathered from the most-recent version of qemu we have
> required for our tests (which is most of the time based on GIT version
> of qemu if there are any significant new features).
>
> If the deprecation will be expressable by the schema it should be rather
> simple to modify the schema validator to catch the deprecation flags and
> report errors in our testsuite.

... we can certainly make it if it's useful.

> CI-ifying of the above should be then also very simple. We'd just gather
> fresh QMP schema rather than using one from our test case pantry.
>
> Some time ago I also added testing of the commandline generator in
> libvirt with the most recent capabilities rather than using the
> historically declared capabilities that we've added when the test was
> created. This means that we actually test some valid combinations and
> also if stuff covered by our capability probing is removed the tests
> will catch it.
>
> I was also thinking of adding a tool which would use the above tests to
> attempt starting of a qemu process until the monitor shows up. That test
> then could also use -no-deprecated-options. I'm hoping waiting for the
> monitor is sufficient to excercise most of the code which could contain
> deprecation warnings. (Alternatively we can go through the
> pre-cpu-startup setup done on the monitor as well). Unfortunately doing
> this will not be as simple asi the test cases contain random disk paths
> and other resources which may not be available. This means that it will
> require some in-place modification and creative temporary resource
> usage.

Yes.

If you find QEMU makes testing something hard, we should talk.  Together
we might find a reasonable way to make it easier.