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