Marc-André Lureau <marcandre.lureau@gmail.com> writes:
Hi
On Tue, Mar 17, 2020 at 12:55 PM Markus Armbruster <armbru@redhat.com> wrote:
This series extends QMP introspection to cover deprecation. Additionally, new option -compat lets you configure what to do when deprecated interfaces get used. This is intended for testing users of the management interfaces. It is experimental.
-compat deprecated-input=<in-policy> configures what to do when deprecated input is received. Available policies:
* accept: Accept deprecated commands and arguments (default) * reject: Reject them * crash: Crash
-compat deprecated-output=<out-policy> configures what to do when deprecated output is sent. Available output policies:
* accept: Emit deprecated command results and events (default) * hide: Suppress them
For now, -compat covers only deprecated syntactic aspects of QMP. We may want to extend it to cover semantic aspects, CLI, and experimental features.
I suggest to use a qmp- prefix for qmp-related policies.
The interface is general. The implemented infrastructure is QAPI-only. Its application is QMP-only. If our CLI was QAPIfied, I'd certainly apply it there, too. I intend to resume exploring CLI QAPIfication "real soon now". Not covering CLI now is a bit like not covering semantic aspects of QMP. Imagine the thing covered CLI. Would we want to have separate -compat deprecated-qmp-input, deprecated-cli-input? I doubt it. I think we want a single policy for all host interfaces. Imagine it covered deprecated semantic aspects of QMP. Would we want to have a separate flag for that? Again, I doubt it. For what it's worth, the interface is documented as experimental.