On Fri, May 10, 2019 at 08:19:52AM +0200, Markus Armbruster wrote: > 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.
I don't see how that applies to machine type and CPU model names. Machine type and CPU model names are often exposed directly to the end user. -- Eduardo
