Re: [PATCH v4 00/34] Configurable policy for handling deprecated interfaces

[Markus Armbruster]

Marc-André Lureau <address@hidden> writes:

> Hi
>
> On Tue, Mar 17, 2020 at 12:55 PM Markus Armbruster <address@hidden> 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.