On Fri, May 10, 2019 at 08:28:04AM +0200, Markus Armbruster wrote: > Eduardo Habkost <ehabk...@redhat.com> writes: > > > On Thu, May 09, 2019 at 05:08:11PM +0100, Daniel P. Berrangé wrote: > >> On Thu, May 09, 2019 at 12:52:47PM -0300, Eduardo Habkost wrote: > >> > 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"? > >> > >> I was refering to libvirt here. > >> > >> > > 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. > >> > >> For some aspects of QEMU it might be possible, but considering the > >> broader set of things which can be deprecated, I don't think it is > >> possible to expose a machine consumable "suggestion". > >> > >> Consider the deprecation of the ACL feature. We deprecated monitor > >> commands "acl_add", "acl_policy", "acl_reset", etc. The suggested > >> replacement is to use one of the many possible QAuthZ types combined > >> with the -object arg. Even if we invented some way to express this > >> in the schema, I don't think any app would usefully consume it. > > > > No problem, we don't need to suggest a machine consumable > > alternative for everything. > > Sure, but we need to get enough value out of it to justify its cost. > > > I'm thinking about features that are visible to the end user and > > require user action to fix their configuration, like machine type > > versions or CPU model versions. > > Even those may need translation as we cross layers of the stack. > > The fewer cases we have where the machinery for machine-readable > deprecation advice is actually useful, the worse its cost / benefit > ratio is going to be.
Are you arguing the cost is unreasonably large? I still don't see what the problem is, here. -- Eduardo
