[PATCH v4 00/34] Configurable policy for handling deprecated interfaces
Markus Armbruster
armbru at redhat.com
Tue Mar 17 15:32:45 UTC 2020
Marc-André Lureau <marcandre.lureau at gmail.com> writes:
> Hi
>
> On Tue, Mar 17, 2020 at 12:55 PM Markus Armbruster <armbru at 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.
More information about the libvir-list
mailing list