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

[Luiz Capitulino]

On Tue, 10 Jan 2012 13:18:41 -0600
Anthony Liguori <anthony at 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.

> 
> >> Now we could change this command to make it a better QMP interface and we could
> >> do that in a compatible fashion.
> >>
> >> However, since I think we'll get proper async support really soon and that will
> >> involve fundamentally changing this command (along with a bunch of other
> >> commands), I don't think there's a lot of value in making cosmetic changes right
> >> now.  If we're going to break backwards compatibility, I'd rather do it once
> >> than twice.
> >
> > It goes beyond cosmetic changes. For example, will we allow other async
> > block commands to use this interface? And if we're doing this for block,
> > why not accept something similar for other subsystems if someone happen to
> > submit it?
> 
> Yes, I'm in agreement with you on direction.  But adding proper async support is 
> not a simple task, and blocking this interface based on that is a bad idea for 
> reasons previously mentioned.
> 
> > Let me take a non-cosmetic change request example. The BLOCK_JOB_COMPLETED
> > event has a 'error' field. However, it's impossible to know which error
> > happened because the 'error' field contains only the human error description.
> 
> Ok.  That's worth thinking about.
> 
> > Another problem: the event is called BLOCK_JOB_COMPLETED, but it's tied
> > to the streaming API. If we allow other commands to use it, they will likely
> > have to add fields there, making the event worse than it already is.
> 
> 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...

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

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