5:07 a.m.
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.
--
Thanks,
Christophe de Dinechin (IRC c3d)