On Tue, 18 May 2010 17:16:54 +0100 "Daniel P. Berrange" <berrange@xxxxxxxxxx> 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@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
