Re: [Qemu-devel] [RFC] New Migration Protocol using Visitor Interface

[Daniel P. Berrange]

On Mon, Oct 03, 2011 at 11:05:02AM -0500, Anthony Liguori wrote:
> On 10/03/2011 10:45 AM, Michael S. Tsirkin wrote:
> >>BTW, putting this info properly into migration stats would probably
> >>be pretty useful.
> >>
> >>Regards,
> >>
> >>Anthony Liguori
> >
> >Problem is adding anything to monitor makes me worry
> >about future compatibility so much I usually just give up.
> >IMO we really need a namespace for in-development experimental
> >commands, like "unsupported-XXX", this would belong.
> 
> Or just make all of QMP unsupported across any given version.  I'm
> not kidding about that actually.
> 
> If we document what the protocol is for any given version, then a
> layer like libvirt can deal with providing a consistent interface.
> 
> I often wonder who we're trying to preserve compatibility for.  Part
> of libvirt's mission statement is providing a stable API so why not
> leverage that mission and get us out of the compatibility business.

You are correct, that ultimately libvirt should be isolating applications
from any changes in QEMU's monitor protocol that take place across
versions. We just ask that QEMU try not to make too many gratuitous
changes, if it is reasonable to avoid them without negative impact on
QEMU. The more time we have to spend adding support for different
commands across each QEMU release, the less time we have to spend on
adding useful features elsewhere.

To me the biggest benefit of QMP is not that the commands are to be
supported long term, but rather than it is a sanely parsable format
with detectable error reporting and asynchronous events.

The important thing to us, is not to make semantic changes to any
*existing* commands. If an existing command is flawed, either leave
it alone & introduce a new one, or if compatibility can't be maintained
for some reason remove the old one & introduce a new one with a *new*
name to avoid any confusion.

So if you have to deprecate some existing QMP commands and introduce
new ones to replace them across releases we can & will cope with that
in libvirt.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|