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@xxxxxxxxxx> 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@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
