Marc-André Lureau <marcandre.lureau(a)gmail.com> writes:
Hi
On Tue, Mar 17, 2020 at 12:55 PM Markus Armbruster <armbru(a)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.