qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info throug


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP
Date: Fri, 10 May 2019 14:00:52 -0300
User-agent: Mutt/1.10.1 (2018-07-13)

On Fri, May 10, 2019 at 08:19:52AM +0200, Markus Armbruster wrote:
> Eduardo Habkost <address@hidden> 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 <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]