Peter Krempa <pkrempa@xxxxxxxxxx> writes: > On Thu, Jul 12, 2018 at 08:38:25 +0200, Markus Armbruster wrote: >> Kevin Wolf <kwolf@xxxxxxxxxx> writes: >> > Am 10.07.2018 um 16:22 hat Cornelia Huck geschrieben: >> >> On Tue, 10 Jul 2018 07:59:15 +0200 >> >> Markus Armbruster <armbru@xxxxxxxxxx> 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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
