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

[Anthony Liguori]

On 01/10/2012 02:55 PM, Luiz Capitulino wrote:
> On Tue, 10 Jan 2012 13:18:41 -0600
> Anthony Liguori<address@hidden>  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