Peter Krempa <pkrempa@xxxxxxxxxx> writes: > 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. I sympathize. However, it's not clear which one's harder, providing environments for a sufficiently wide range of configurations (possibly mockups), or hacking QEMU to do nothing but check configuration. QEMU isn't designed for that, and configuration checking is intertwined with everything else. Complete disentanglement looks impractical to me. I guess we could do something useful at the QAPI level, though. Yet another reason to qapify the command line... > 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. I don't think end users should do the work of catching use of deprecated features. It's a CI job. In a CI context, we don't need fancy QMP infrastructure to communicate "you used a deprecated feature", we can get away with printing an explanation to stderr and exit(1). That should make CI fail, and the failure should make a developer read the explanation. To unbreak CI, he can either fix the problem right away, or file a BZ and suppress the CI failure until it's fixed, say by downgrading --deprecated=error to --deprecated=warn. [...] -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
