[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: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP |
Date: |
Fri, 10 May 2019 08:28:04 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Eduardo Habkost <address@hidden> 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 <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"?
>>
>> 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.
- Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP, Markus Armbruster, 2019/05/07
- Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP, Eduardo Habkost, 2019/05/07
- Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP, Markus Armbruster, 2019/05/08
- Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP, Eduardo Habkost, 2019/05/08
- Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP, Markus Armbruster, 2019/05/09
- Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP, Daniel P . Berrangé, 2019/05/09
- Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP, Eduardo Habkost, 2019/05/09
- Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP, Daniel P . Berrangé, 2019/05/09
- Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP, Eduardo Habkost, 2019/05/09
- Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP,
Markus Armbruster <=
- Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP, Eduardo Habkost, 2019/05/10
- Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP, Markus Armbruster, 2019/05/10
- Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP, Eduardo Habkost, 2019/05/10
- Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP, Eduardo Habkost, 2019/05/09
- Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP, Markus Armbruster, 2019/05/10
- Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP, Eduardo Habkost, 2019/05/10
- Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP, Daniel P . Berrangé, 2019/05/10
- Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP, Markus Armbruster, 2019/05/13