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

[Luiz Capitulino <lcapitulino@redhat.com>]

On Tue, 10 Jan 2012 15:02:48 -0600
Anthony Liguori <aliguori@us.ibm.com> wrote:

> 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?

It's just a few proposals for the high-level API (ie. no patches), I can send it
tomorrow.

> 
> 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
> >>
> >
>