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

[Markus Armbruster]

Eduardo Habkost <address@hidden> writes:

> On Tue, May 07, 2019 at 07:07:04AM +0200, Markus Armbruster wrote:
>> Eduardo Habkost <address@hidden> 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.

Valid point.  Still, I believe we should at least try to predict how the
pieces we create now would fit with the pieces we plan to create later
on.

Note that full QAPIfication of -machine isn't necessary to make QAPI
feature "deprecated" work for machine types.  Turning MachineInfo member
@name into an enum, so we can tack "deprecated" onto its values, would
suffice.

Such a QAPIfication of machine types is still hard: QOM types are
defined at compile time just like the QAPI schema, but their definition
is distributed, and collected into one place only at run time.  I
discussed this on slide 39 of my "QEMU interface introspection: From
hacks to solutions" talk (KVM Form 2015).  Just for device_add, but it's
just a special case of QOM.  Choices listed there:

* Collect drivers at compile time? Hard...
* Make QAPI schema dynamic? Hard...
* Forgo driver-specific arguments in schema?
  Defeats introspection...

I'd like to add to the last item:

  Provide QOM introspection on par with QAPI schema introspection

The QOM introspection we have (qom-list-types etc. is not on par.

Back to exposing machine type deprecation.

I'm doubtful your proposed solution can be applied widely.  It relies on
adding @support-status to something that provides information on
whatever is deprecated.  The initial use is with a something that is an
ad hoc query, namely query-machines.  To use it, the management
application needs to understand what query-machines' @support-status
applies to.  Certainly feasible.  But I fear every use will be a special
case.  Furthermore, a suitable ad hoc query need not exist.  What then?
Create suitable ad hoc queries just for communicating deprecation?

Instead, I'd like us to think about a more genral solution.  Or perhaps
two: one for properly QAPIfied stuff, and one for QOM.

>> 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).

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.

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

I'm confident we can come up with *something*.  It might kill the neat
and simple "use QAPI features to communicate deprecation" idea, though.

>> 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: <address@hidden>