On Wed, May 15, 2019 at 12:58:46 +0200, Kevin Wolf wrote: > Am 18.04.2019 um 22:03 hat Markus Armbruster geschrieben: > > Kevin Wolf <kw...@redhat.com> writes: > > > > > Sometimes, the behaviour of QEMU changes compatibly, but without a > > > change in the QMP syntax (usually by allowing values or operations that > > > previously resulted in an error). QMP clients may still need to know > > > whether the extension is available. > > > > > > This allows to add a list of features to struct definitions that will be > > > made visible to QMP clients through schema introspection. > > > > Only a first step, but that's okay. I think we want to be able to tack > > features to all user-defined types, commands, and events. Ideally even > > to members of enum and object types. > > > > Use case: feature 'deprecated'. We talked about ways to communicate > > deprecation to management applications. Introspection was proposed. > > Feature 'deprecated' delivers it. > > How does introspection solve the problem? It requires the client to > actively look for a deprecation instead of notifying it that it is using > something deprecated.
Well, we can actively poll .. > Do you expect libvirt to check a full list of all QMP commands, types, > etc. it ever uses against the schema after starting a VM or something > like that? .. similarly to how we asked to be put on the reviewer list for the deprecated. We an use our test data which we gather from qemu periodically which include the QMP schema to extract the list of deprecated features and store them in git. If we bump the test data and a new deprecated entry appears the developers will need to asses whether it's used or not and take the appropriate action. The appropriate action may also include deriving a capability information from it and use it to alter libvirt's behaviour which would then be queried at startup of the VM, but mostly we want to use the new approach which will replace given deprecated feature as soon as it's available.
signature.asc
Description: PGP signature
