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

On Thu, Jul 12, 2018 at 08:38:25 +0200, Markus Armbruster wrote: > Kevin Wolf <kwolf(a)redhat.com&gt; writes: > > Am 10.07.2018 um 16:22 hat Cornelia Huck geschrieben: > >> On Tue, 10 Jul 2018 07:59:15 +0200 > >> Markus Armbruster <armbru(a)redhat.com&gt; 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.

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.

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.