[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Markus Armbruster
Subject: Re: [PATCH v4 00/34] Configurable policy for handling deprecated interfaces
Date: Tue, 17 Mar 2020 16:32:45 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]