Re: [Qemu-devel] [libvirt] QMP: Supporting off tree APIs

[Anthony Liguori <aliguori@us.ibm.com>]

On 01/10/2012 02:55 PM, Luiz Capitulino wrote:
> On Tue, 10 Jan 2012 13:18:41 -0600
> Anthony Liguori<anthony@codemonkey.ws>  wrote:
>
>> On 01/06/2012 01:42 PM, Luiz Capitulino wrote:
>>> On Fri, 06 Jan 2012 09:08:19 -0600
>>>> We also need to look at this interface as a public interface whether we
>>>> technically committed it to or not.  The fact is, an important user is relying
>>>> upon so that makes it a supported interface.  Even though I absolutely hate it,
>>>> this is why we haven't changed the help output even after all of these years.
>>>> Not breaking users should be one of our highest priorities.
>>>
>>> One thing I don't understand: how is libvirt relying on it if it doesn't
>>> exist in qemu.git yet?
>>
>> Because there was a discussion on qemu-devel and we agreed on an interface that
>> both sides would implement to.
>>
>> I expect this to happen more often in the future too.
>
> For future commands we either, implement it right away or ask libvirt to
> wait for the command to be merged, or at least pass initial review.

Or commit the schema entry to qapi-schema.json with gen=False.

But when this command was first proposed, qapi-schema.json didn't exist in the 
tree :-)

>> But aren't we going to introduce a proper async interface?  This is what has me
>> confused.
>
> Yes, I was thinking about new block commands using this API before we get
> proper async support...

Well let's avoid that problem by doing proper async support before we get new 
block commands ;-)

>>> There's more, because I skipped this review in v3 as I jumped to the
>>> "proper async support" discussion...
>>
>> Well let's do proper async support.  As I mentioned, I'd rather take this
>> command in as-is, introduce proper async support, and then deprecate a bunch of
>> stuff at once.
>
> Ok, I'm willing to do this as Stefan has agreed on deprecating this as soon as
> we get proper async support.

Excellent.

BTW, you mentioned that you were going to send an RFC for proper async support?

Regards,

Anthony Liguori

>>
>>>> What I'd suggest is that we take the command in as-is and we mark it:
>>>>
>>>> Since: 1.1
>>>> Deprecated: 1.2
>>>> See Also: TBD
>>>>
>>>> The idea being that we'll introduce new generic async commands in 1.2 and
>>>> deprecate this command.  We can figure out the removal schedule then too.  Since
>>>> this command hasn't been around all that long, we can probably have a short
>>>> removal schedule.
>>>
>>> That makes its inclusion even discussable :) A few (very honest) questions:
>>>
>>>    1. Is it really worth it to have the command for one or two releases?
>>
>> Yes.  The most important consideration IMHO is parallelizing development.  We
>> want the block layer to evolve to the greatest extent possible independent of
>> our other subsystems.  If we don't have the right infrastructure in QMP to
>> support a block feature, that shouldn't hold up progress in the block layer to
>> the greatest extent possible.
>>
>>>    2. Will we allow other block commands to use this async API?
>>
>> Depends on how long it takes to do "proper async support".
>>
>>>    3. Are we going to accept other ad-hoc async APIs until we have a
>>>       proper one?
>>
>> Yes.  So let's get serious about getting a proper interface in :-)
>
> ACK
>
>>
>> Regards,
>>
>> Anthony Liguori
>>
>