On Wed, May 15, 2019 at 15:48:29 +0200, Markus Armbruster wrote: > Kevin Wolf <kw...@redhat.com> writes: > > Am 18.04.2019 um 22:03 hat Markus Armbruster geschrieben: > >> Kevin Wolf <kw...@redhat.com> writes:
[...] > > Do you expect libvirt to check a full list of all QMP commands, types, > > etc. it ever uses against the schema after starting a VM or something > > like that? > > I'm merely responding to demand. > > Subject: Minutes of KVM Forum BoF on deprecating stuff > Message-ID: <87mur0ls8o....@dusky.pond.sub.org> > > * We need to communicate "you're using something that is deprecated". > How? Right now, we print a deprecation message. Okay when humans use > QEMU directly in a shell. However, when QEMU sits at the bottom of a > software stack, the message will likely end up in a log file that is > effectively write-only. > > - The one way to get people read log files is crashing their > application. A command line option --future could make QEMU crash > right after printing a deprecation message. This could help with > finding use of deprecated features in a testing environment. > > - A less destructive way to grab people's attention is to make things > run really, really slow: have QEMU go to sleep for a while after > printing a deprecation message. > > - We can also pass the buck to the next layer up: emit a QMP event. > > Sadly, by the time the next layer connects to QMP, plenty of stuff > already happened. We'd have to buffer deprecation events somehow. > > What would libvirt do with such an event? Log it, taint the domain, > emit a (libvirt) event to pass it on to the next layer up. > > - A completely different idea is to have a configuratin linter. To > support doing this at the libvirt level, QEMU could expose "is > deprecated" in interface introspection. Feels feasible for QMP, > where we already have sufficiently expressive introspection. For > CLI, we'd first have to provide that (but we want that anyway). From all of the above, the most important bit is still that the libvirt developers at first identify sooner rather than later that something is deprecated. That way we can either make sure to not use it any longer if there's a compatible replacement or perhaps add the aforementioned linter to print a warning that the config may not be supported in some time. The linter will still require us seeing what is deprecated, so marking that in the schema is useful. There are two dimensions to this though. QMP is the first, where introspection is awesome. Then there is command line and it's various commands which don't have QMP counterparts and that doesn't work that well there. In normal operation there's not much we can do here as refusing to use deprecated attributes or commands would cause regressions. In the test suite we are already validating the output of some of our tests against the QMP schema so making those fail when they are deprecated is certainly possible but not very likely to ever catch something as our QMP tests are exremely basic. It would be much more potent to have something like this to allow validating the command line automatically, but this would require using some structured format first. Without that it's really up to us implementing a check for every unsupported feature as we figure out it's deprecated rather than having it done automatically. Things got way better after we got CC'd on the deprecation document, since we can make sure that we don't use the particular removed thing. There are still a few things that are not addressed which were present before this was happening. E.g. we don't specify the full NUMA topology on the commandline and get an angry message back on the command line. This is going on for almost a year now and nobody complained. Stderr messages are ineffective.
signature.asc
Description: PGP signature
