Re: [Qemu-devel] qapi: Stop abusing "special" values for something entirely different

[Markus Armbruster <armbru@redhat.com>]

Eric Blake <eblake@redhat.com> writes:

> On 07/14/2017 12:12 PM, Markus Armbruster wrote:
>> 
>> Instead of the last part, I prefer either
>> 
>> * so we add a *new* value, such as JSON null.
>
> I like that idea.
>
>> 
>> 1. Stop abusing values the schema accepts, but are invalid to mean "do
>> something else entirely".
>> 
>> 2. Add a first class null type to QAPI.
>> 
>> 3. Turn MigrationParameters members tls-creds and tls-hostname into
>> alternate of str and null.  Deprecate "".
>> 
>> 4. Add a null member to alternate BlockdefRef.  Deprecate "".
>
> Back-compat concerns: would we still accept "" in place of null for a
> release or two?

Yes.

>                  Is it time to figure out how to add deprecation
> notices/events to QMP?

Yes, getting that in the next development cycle would be nice.

>                         Or would this be a clean break-over point (since
> introspection exists), where if introspection shows there is an
> alternate between string and null, then libvirt MUST use null instead of
> "" to get the desired semantics?

Feels unnecessarily harsh to me.

>> I got patches for 2., and I intend to work on 3. and 4.
>> 
>> Since this is "only" about "less than general and ugly", we may decide
>> to leave things as they are if my patches turn out even uglier.
>> 
>> Meanwhile, opinions?
>
> Not much time left for soft freeze (which kind of echoes the dilemma we
> had at 2.9).  Is this something you are aiming for in 2.10, or will it
> be all the harder to worry about back-compat (because we'll have two
> releases rather than one before we introduce the alternate-with-null
> semantics)?

Let's try to get it into 2.10.