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

[Eduardo Habkost <ehabkost@redhat.com>]

On Tue, May 07, 2019 at 07:07:04AM +0200, Markus Armbruster wrote:
> Eduardo Habkost <ehabkost@redhat.com> writes:
> 
> > This series adds machine type deprecation information to the
> > output of the `query-machines` QMP command.  With this, libvirt
> > and management software will be able to show this information to
> > users and/or suggest changes to VM configuration to avoid
> > deprecated machine types.
> 
> This overlaps with something I want to try, namely using Kevin's
> proposed QAPI feature flags for deprecation markings.  Let's compare the
> two.
> 
> To mark something as deprecated with your patches, you add a
> @support-status member somewhere, where "somewhere" is related to
> "something" by "provides information on".
> 
> Example: MachineInfo (returned by query-machines) provides information
> on possible values of -machine parameter type.  If -machine was
> QAPIfied, it would provide information on possible values of a QAPI
> object type's member.  The type might be anonymous.  The member should
> be an enum (we currently use 'str' in MachineInfo).

QAPIfying -machine, -cpu, and -device would be wonderful.

> 
> Example: say we want to deprecate block driver "vfat",
> i.e. BlockdevDriver member @vfat.  Type BlockdevDriver is used in
> multiple places; let's ignore all but BlockdevOptions.  We need to add
> @support-status to something that provides information on
> BlockdevDriver, or maybe on BlockdevOptions.  There is no ad hoc query
> providing information on either of the two, because QAPI/QMP
> introspection has been sufficient.  What now?
> 
> Can we add deprecation information to (general) QAPI/QMP introspection

Yes, we can.  I think it's a good idea.  But:

> instead of ad hoc queries?

I'm not sure about the "instead of" part.  I don't want perfect
to be the enemy of done, and I don't want QAPIfication of
-machine to be a requirement to start reporting machine type
deprecation information.

> 
> Kevin's proposed QAPI feature flags[*] extend the QAPI language so that
> struct types can optionally have a list of feature flags, which are
> strings.  Struct types suffice for his immediate needs.  I'd like to use
> feature flags to mark deprecation by tacking a "deprecated" feature onto
> whatever is deprecated.  This obviously needs feature support for
> everything we want to be able to deprecate: commands, and events, as
> well as members of enum and object types.
> 
> Example: to deprecate block driver "vfat", add feature "deprecated" to
> BlockdevDriver member @vfat.
> 
> Unlike your patches, this does not require finding a "somewhere" that
> provides information on "something".  You simply tack "deprecated" right
> onto "something".
> 
> Your patches provide more information, however: human-readable messages.

It also includes a machine-friendly suggested alternative (which
I think is even more important that the human-readable message).

We could extend QAPI introspection to return that if necessary,
right?


> 
> Food for thought :)
> 
> 
> [*] Hiding in
> Subject: [PATCH 0/4] file-posix: Add dynamic-auto-read-only QAPI feature
> Date: Mon,  8 Apr 2019 16:35:39 +0200
> Message-Id: <20190408143543.3982-1-kwolf@redhat.com>

-- 
Eduardo