John Snow writes:
> On 8/29/19 12:45 PM, Christophe de Dinechin wrote: >> [...] >> Sorry for catching up late, this mail thread happened during my PTO. >> >> I remember bringing up at the time [1] that the correct solution needs >> to take into account usage models that vary from >> >> - a workstation case, where displaying an error box is easy and >> convenient, >> >> - to local headless VMs where system-level notification would do the job >> better, allowing us to leverage things like system-wide email notifications >> >> - to large-scale collections of VMs managed by some layered product, >> where the correct reporting would be through something like Insights, >> i.e. you don't scan individual logs, you want something like "913 VMs >> are using deprecated X" >> >> To me, that implies that we need to have a clear division of roles, with >> a standard way to >> >> a) produce the errors, >> b) propagate them, > > I started replying to this thread to the other mail you sent; I think > this is going to be fairly involved. I wouldn't mind being proven wrong > though. Yes, I think it does look involved, but mostly for historical reasons. In other words, what is complicated is preserving the historical behaviors so as to not break existing consumers. > >> c) consume them (at least up to libvirt) >> >> Notice that this work has already been done for "real" errors, >> i.e. there is a real QAPI notion of "errors". AFAICT, warn_report does >> not connect to it, though, it goes through error_vprintf which is really >> just basic logging. >> >> So would it make sense to: >> >> 1. Add a deprecation_report() alongside warn_report()? >> > > Where's that get routed to? just an error_vprintf style situation? Yes, but see below. > >> 2. Connect warn_report() and all the error_vprintf output to QAPI, >> e.g. using John's suggestion of adding the messages using some >> "warning" or "deprecated" tag? >> > > How do you correlate them? Without having looked at the code much, I think I would 1. extend the existing QAPI error to support warnings, deprecations and info messages. The first problem I see is that there is no error, so we may sometimes need to create one when there was none before. And of course make sure that this does not ultimately show as an error, but as a success with additional annotations. 2. replace the current "link + if" switching for error_vprintf with some actual notification mechanism, with one option routine to monitor_vprintf, one to stderr, one to log file, and then an additional path that would post a newly minted qapi warning. > >> 3. Teach libvirt how to consume that new tag and pass it along? >> > > I think it's not libvirt's job to pass it along, exactly -- libvirt made > the decision for which features to engage in QEMU, not the end user. First, by "pass along", I meant to possible layered products or management software. We don't necessarily need a new virErrorLevel, deprecation could be a warning with some special domain, e.g. VIR_FROM_DEPRECATION. There may be a need to add some API here. Looking at the code, it's not obvious to me that libvirt has any notion of error priority. In other words, if you raise an error then a warning, you get the warning as the last error, right? Second, why not report the use of deprecated features? I don't fully buy the rationale that libvirt engages the features, because it does not do it on its own, it does it because the user made some specific request. This point of view also seems to require that libvirt or the user should know ahead of time it's about to engage a deprecated feature. To me, the problem is precisely that neither libvirt nor the user knows, which is why we are discussing how to best make it known. > > If the user upgrades QEMU but not libvirt, it's not really anything they > have control over and they shouldn't be pestered with such things. > > However, if libvirt accidentally released a version that engages > deprecated behavior (and were unaware of it), it'd be nice to get user > reports, surely? > > Logging messages for libvirt might be the best that can be done there in > that case. I personally would treat that like any warning. > > > In contrast, power user tools like QMP libraries, qmp-shell and others > allow more direct and meaningful access to QMP, so those should report > deprecation messages to the user. Agreed. > >> >> [1] https://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg06131.html >> -- Thanks, Christophe de Dinechin (IRC c3d)
