Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file

[Avi Kivity <avi@redhat.com>]

On 06/25/2009 09:09 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
>>> An RPC is overkill unless you also introduce things like life cycle 
>>> management.  Otherwise, you could never realistically interact with 
>>> QEMU without a intermediary that handled life cycle management (e.g. 
>>> libvirt).
>>
>> QMP is an RPC implemented over a text based protocol, with ad-hoc 
>> marshalling.
>>
>> I agree that you need something to reap dead qemus, but I don't think 
>> we can force libvirt on people.
>
> QMP is an incremental improvement to the current monitor which people 
> are consuming today.  It will have a pretty immediate and high rate of 
> return.  libvirt can make use of it with probably very little change 
> and it will immediately provide them with new features (async 
> notifications) and better information about commands (error return 
> values).
>

The incremental cost of porting a monitor command, documenting its 
format, improving QMP infrastructure where necessary, and implementing 
that command across all clients is much greater than RPC.  For a new 
client implemented in a high level language, using QMP will be 
substantially more difficult than using RPC, and the probability of 
getting things right will be much greater.

Targeting libvirt alone is a mistake.  Of course libvirt is a very 
important user of the qemu monitor, but not doing the right thing 
because libvirt has some prior art is shortsighted IMO.  RPC offers the 
best choice for growth, in adding new commands, and in supporting more 
clients.

> I have a really hard time not thinking this is the right thing to do 
> because for relatively little churn we'll get a large return.  If you 
> just exposed the monitor as an RPC, I don't think you really get 
> anything more useful than QMP and you force a lot more change in 
> libvirt which hurt the adoption of this protocol.

Adopting an RPC should be easier than adopting QMP, since all you have 
to do is compile the IDL.  Again I point to the incremental cost of 
adding a command.

> This is exactly what happened with Xend's transition from SExpr/HTTP 
> (custom RPC) -> XML-RPC -> XenAPI.  libvirt still uses SExpr/HTTP 
> because the cost of switching to the new way of doing things didn't 
> warrant the return on investment.

I think this points to libvirt doing something wrong.  I suspect it's 
the implementation language.

> s/libvirt/any other management tool that works today/g

Anything written in a high level language (say, Python) will be trivial 
to port to an RPC.  RPC clients in Python can be typed in with one 
finger in a couple of minutes.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.