Re: [Qemu-devel] Re: KVM call agenda for May 18

[Luiz Capitulino <lcapitulino@redhat.com>]

On Tue, 18 May 2010 17:16:54 +0100
"Daniel P. Berrange" <berrange@redhat.com> wrote:

> On Tue, May 18, 2010 at 01:00:40PM -0300, Luiz Capitulino wrote:
> > On Tue, 18 May 2010 15:55:41 +0100
> > "Daniel P. Berrange" <berrange@redhat.com> wrote:
> > 
> > > On Tue, May 18, 2010 at 09:34:06AM -0500, Anthony Liguori wrote:
> > > > On 05/18/2010 09:09 AM, Daniel P. Berrange wrote:
> > > > >On Tue, May 18, 2010 at 08:53:19AM -0500, Anthony Liguori wrote:
> > > > >   
> > > > >>On 05/17/2010 10:23 PM, Chris Wright wrote:
> > > > >>     
> > > > >>>Please send in any agenda items you are interested in covering.
> > > > >>>
> > > > >>>If we have a lack of agenda items I'll cancel the week's call.
> > > > >>>
> > > > >>>       
> > > > >>- Slipping 0.13 release out to July 1st.
> > > > >>     
> > > > >What is the plan wrt QMP and 0.13 ? Is the intention to have 100%[1] of the
> > > > >existing monitor commands converted to QMP?
> > > > 
> > > > No.  I don't think our goal is to ever fully convert monitor commands to 
> > > > QMP.  Some commands simply don't make sense as QMP commands (like x and xp).
> > > 
> > > We're a really long way from a complete conversion even  ignoring 
> > > commands which don't make sense in QMP. The current state almost 
> > > covers the commands libvirt currently uses, but there's much more 
> > > beyond that.
> > 
> >  As far as I understood it, the plan for the first QMP release has always
> > been to only convert the subset of commands relevant/used by libvirt.
> 
> Well we've evolved the plan several times since QMP started & the set
> of commands used by libvirt has evolved too! So I just want to define 
> exactly what we're proposing to support for 0.13 release.

 The current set of libvirt used commands plus the must haves ones, this is
the maximum we can be committed with for the next release.

 If time allows, I will pick more from the outstanding list.

> > > I don't think we can claim all those are irrelevant for QMP.
> > > 
> > > So are we still targetting complete conversion of relevant commands
> > > for 0.13, or is it just going to be a stepping stone where declare 
> > > QMP stable, but known to be incomplete for coverage of commands ?
> > 
> >  The first thing to do is to agree on what a 'complete coverage' would be,
> > what we have been trying to do since January is to provide a complete set
> > for libvirt, our unique well known client so far.
> > 
> >  Apart from the 'outstanding' set above, can you elaborate on how
> > QMP on 0.13 would not satisfy libvirt needs?
> 
> The must haves are blockdev_add, and the commit/delvm/loadvm/savevm
> stuff, since they're already in use. 
> 
> The problem I fear is that we're aiming for a moving target here.
> 
> eg, by the time QEMU 0.13 comes out libvirt may have received patches
> using yet more QEMU monitor commands. So the list I mention above is
> my best guesstimate at the commands that could appear in libvirt in
> the not too distant future. The more of those we can support the better
> so that we avoid geting into a case where QEMU 0.13 is released, but a
> yet newer libvirt wants extra QMP commands that weren't included in 0.13.

 This problem isn't 0.13 specific as I expect new Monitor commands to
be added in qemu at every release. It's true that QMP makes this more
evident due its limited set, still we have to deal with the fact that
the command set is always going to be extended.

 Here's what I think we should do:

1. Clients should check for the availability of commands by issuing
   query-commands. Eg.

   A) Issue query-commands at startup and cache its output
   B) Before issuing any command, check whether it's supported
   C) Issue an error message if the command is not supported

2. Both projects should work closely, so that features are in sync at
   every release

3. We could create an official 'priority list' in qemu's tree, with
   a listing of commands to be converted for the next release and
   clients should work closely by suggesting changes to this list