Eduardo Habkost <ehabk...@redhat.com> writes: > On Thu, May 09, 2019 at 10:14:52AM +0100, Daniel P. Berrangé wrote: >> On Thu, May 09, 2019 at 10:31:46AM +0200, Markus Armbruster wrote: >> > We've wandered into the QAPI vs. QOM swamp. Cc: Paolo. >> > >> > Eduardo Habkost <ehabk...@redhat.com> writes: >> > >> > > On Wed, May 08, 2019 at 11:16:50AM +0200, Markus Armbruster wrote: [...] >> > >> I agree we should point to a preferred replacement whenever we deprecate >> > >> something. >> > >> >> > >> We have to do it in documentation. And we generally do, in >> > >> qemu-deprecated.texi. >> > >> >> > >> How useful would doing it in QMP as well be? Depends on what management >> > >> applications can do with the additional information. >> > > >> > > I expect it to be useful for things that have obvious >> > > replacements, like old machine type or CPU model versions. >> > >> > I doubt a management application should apply suggested replacements >> > automatically, and I doubt libvirt would. Not even when QEMU developers >> > deem them "obvious". >> >> We certainly won't apply the suggested replacement as in many cases >> it is not going to be a functionally equivalent drop-in. > > Who's "we"? > >> >> If QEMU logs it to stderr, it will end up in the per-VM log file >> libvirt has under /var/log/libvirt/qemu/$GUESTNAME.log. If QEMU >> doesn't log it to stderr, then libvirt would just write it to >> that same log file itself. >> >> If libvirt gains some API or event for notifying apps of deprecation >> we might bubble it up to the mgmt app that way. >> >> I still feel it is useful to have the suggested replacement in the >> logs, rather than only leaving it in qemu-deprecated.texi. This >> way the info is immediately visible to both app developers and any >> support person dealing with bugs. >> >> If the app dev see the suggested replacement upfront they're more >> likely to make an immediate decision to update their code if the >> suggestion is trivial. If they need to go find the QEMU docs to >> lookup what action is required I feel they'll more likely just >> put the item on their long todo list where it will languish. > > Agreed. However, note that the audience for deprecation > information is not just developers and support people. End users > need to know when they are relying on a deprecated feature, and > applications should make it as easy as possible for them to > update their configurations. > > I'm not suggesting the alternative would be applied > automatically. But having the alternative available in a > machine-friendly way may be the difference between a unhelpful UI > that just tells the user there's some problem but can't give a > solution, and one that can really assist the user to fix the > problem.
I'm skeptical. For the management application to assist its users, it has to translate both the deprecated QEMU interface and its replacement into its own interfaces (because those are the ones the users actually use). Management applications routinely translate in the other direction. I doubt anyone would build reverse translation capabilities just for helping users update deprecated configurations. So unless such capabilities get built for other purposes, machine-friendliness will remain unused. If the management application's user is another machine, another translation is needed. And so forth until we reach the guy who's supposed to update configuration. Such a game of telephone is unlikely to produce anything but confusion, except for specific cases we test across the whole stack.
