[PATCH v5 0/8] Configurable policy for handling deprecated interfaces
Markus Armbruster
armbru at redhat.com
Mon Sep 21 14:58:19 UTC 2020
Peter Maydell <peter.maydell at linaro.org> writes:
> On Mon, 14 Sep 2020 at 09:55, Markus Armbruster <armbru at redhat.com> wrote:
>>
>> 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.
>
> Some bikeshedding on option naming...
>
> If this only covers QMP, should we make the argument to -compat
> have a name that expresses that? eg deprecated-qmp-input,
> deprecated-qmp-output ?
It's only implemented for QMP so far. But we really want it for all
external interfaces for use by machines. Today, that's QMP and CLI.
Naming the parameters deprecated-qmp-{input,output} leads to separate
settings for QMP and CLI.
Naming them just deprecated-{input,output} leads to a single set of
settings common to all externeal interfaces, or to sugar for setting all
the deprecated-*-{input,output} we may have.
I don't think getting it wrong now would be a big deal. No excuse for
getting it wrong unthinkingly :)
> Also, it seems a bit repetitive to say 'deprecated' here all
> the time -- do you have a future use of -compat in mind which
> would be to adjust something that is *not* deprecated ? If
> not, maybe the 'deprecated' part should be in the option name
> rather than in every argument, eg
>
> -deprecation-compat qmp-input=crash,qmp-output=hide,cli-option=reject
>
> ?
My cover letter hints at such future uses: "We may want to extend it to
cover [...] experimental features." Something like
-compat experimental-input=reject,experimental-output=hide
More information about the libvir-list
mailing list