From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39412) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WrSd1-0008E4-S3 for qemu-devel@nongnu.org; Mon, 02 Jun 2014 09:50:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WrScu-0000el-Ao for qemu-devel@nongnu.org; Mon, 02 Jun 2014 09:50:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31160) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WrScu-0000eL-2x for qemu-devel@nongnu.org; Mon, 02 Jun 2014 09:50:12 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s52Do974008461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 2 Jun 2014 09:50:10 -0400 Date: Mon, 2 Jun 2014 14:50:05 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20140602135004.GF2634@work-vm> References: <1401276034-30486-1-git-send-email-dgilbert@redhat.com> <5385CC10.6030909@redhat.com> <20140528120444.GE2372@work-vm> <871tv7bhyn.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871tv7bhyn.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] [PATCH 0/3] Migrate with destination version List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Paolo Bonzini , quintela@redhat.com, Laszlo Ersek , qemu-devel@nongnu.org, lcapitulino@redhat.com * Markus Armbruster (armbru@redhat.com) wrote: > "Dr. David Alan Gilbert" writes: > > > * Paolo Bonzini (pbonzini@redhat.com) wrote: > [...] > >> Version numbers open a huge compatibility can of worms (what is a version > >> number?) > > > > No, a version number here is very well defined; it's the output of > > query-version' > > (or 'info version' for the HMP world). > > Okay, make it "version numbers are a huge, well-defined compatibility > can of worms" :) > > > How you do comparisons on that, and in particular how you parse the 'package' > > text is a different matter, however I suggest that parsing the 'package' > > text is downstream's problem and they provide that text. > > This means that a downstream has to examine and possibly adapt the > version number conditionals when it backports anything. I was thinking of adding a few routines for version number comparison, in the hope that they would help cover these two problems; but that I really thought didn't make sense until we had some feel about how they would be used. > >> and don't solve the fundamental problem of migration receiving > >> insufficient testing with upstream QEMU versions. > > > > Indeed; and it's not meant to - in no way is this an excuse for inadequate > > testing - however, we're all human, and bugs happen, this is just providing > > a way to get out of some of the mess afterwards. > > Understand. It's a last resort, to be used only when the alternatives > are all even worse. Exactly. > If we put this in, we'll have to review all attempts to use it very > critically: is there really, really no practical alternative? Yep. > Can you explain why we should put it in before we have a user? If we have it in then we can get libvirt to use it. If we have it all in place then if we do hit a compatibility issue where we need to use it, then it's easy. If we don't put it in, then if we hit this type of situation we suddenly need to coordinate a modification of libvirt as well. However, it gets trickier since the destination libvirt has to know to send the version information to the source; so we can only use this trick between versions where the libvirt on both ends knows about it; so if we suddenly hit a compatibility issue where we need it then we'd have to update libvirt on both sides, which is too late. So putting this in now, and getting it into libvirt means everyone has the info. Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK