From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39747) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPu8D-0003ot-3H for qemu-devel@nongnu.org; Wed, 10 Apr 2013 08:28:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UPu8B-0002Eb-ES for qemu-devel@nongnu.org; Wed, 10 Apr 2013 08:28:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39971) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPu4T-0000Ns-RQ for qemu-devel@nongnu.org; Wed, 10 Apr 2013 08:24:14 -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 r3ACOCAn023057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 10 Apr 2013 08:24:12 -0400 Message-ID: <516559EB.8020005@redhat.com> Date: Wed, 10 Apr 2013 06:24:11 -0600 From: Eric Blake MIME-Version: 1.0 References: <877gkavlw2.fsf@blackfin.pond.sub.org> <516544C3.2060306@redhat.com> In-Reply-To: <516544C3.2060306@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2XUWEPPMKKNRKNTIPQDGQ" Subject: Re: [Qemu-devel] [PATCH v4 00/11] convert savevm to use qapi and introduce qmp command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pavel Hrdina Cc: lcapitulino@redhat.com, Markus Armbruster , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2XUWEPPMKKNRKNTIPQDGQ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/10/2013 04:53 AM, Pavel Hrdina wrote: > The first thing what we should discuss is the use of name as tak or > id. I think that the best solution should be that we will have separate= > arguments of both. We will use the 'name' argument to specify the tag > of a snapshot and we will add a new argument named 'id' to specify the > id of the snapshot. > There will be some restriction how to use them. > - If you are creating new snapshot, you could use only the 'name' > argument because the id will be generated. This works. > - If you want to overwrite an existing snapshot, you could specify > the 'id' or the 'name' argument or both of them and also you will > have to use the 'force' argument But the argument made in this thread is that QMP should _not_ have a force argument. It should be a flat-out error in QMP to try to create a snapshot with a conflicting name or tag; preferably with a distinct error type. Higher-level apps (HMP savevm -f) would try to create; if -f is not specified, the error is good enough; if -f is specified and that particular error is returned, then HMP calls delete and then re-tries the create. No 'force' argument needed at the QMP layer. > - I think that the 'name' argument don't need to be mandatory for QMP= > and also for HMP if we will generate the name. Since HMP always generates a tag, and libvirt always generates a tag, I think that teaching 'qemu-img' enough plumbing to modify the tag of an existing snapshot will be sufficient for the purposes of testing loadvm on a tagless snapshot. I'm starting to be convinced that having QMP mandate a tag name, and leaving only qemu-img as the way to create a tagless snapshot, makes more sense. > - We always return/print information about created snapshot that > everyone knows which snapshot has been created. Thus, I'm leaning towards: { 'command': 'vm-snapshot-save', 'data': { 'tag': 'str', '*id': 'int' }, 'returns': 'SnapshotInfo' } Mandatory tag, optional id, no force flag. Addition of a qemu-img snapshot subcommand, which can be used to alter (including removing) the tag of an existing snapshot. >=20 > The loadvm will use also both arguments and with this we will support > snapshots without tags, because you can specify that you want load > the snapshot by 'id' Here, I could see two different options: { 'command': 'vm-snapshot-load', 'data': { '*name': 'str', '*id': 'int' } } Optional name, optional id; with an additional semantic check that at least one was provided, and that if both were provided that they name the same snapshot (but JSON doesn't express this constraint). Or: { 'enum': 'SnapshotLookup', 'data': [ 'id-only', 'tag-only', 'default' ] } { 'command': 'vm-snapshot-load', 'data': { 'name': 'str', '*mode': 'SnapshotLookup' } } where mode defaults to matching 'name' against first 'id' then 'tag', but where 'id-only' and 'tag-only' can refine the search to force 'name' to match only one of the two identifiers. Here, the only semantic constraint that JSON cannot express is that 'name' must be the stringized form of an integer for an id lookup to succeed. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2XUWEPPMKKNRKNTIPQDGQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJRZVnrAAoJEKeha0olJ0NqqIsH/R8c7z8tLoWf+I40E8ZIJaGn M78khL/XiPr5W4ufeBJh+Ip3orz1wAsOCMI89TXgzmkSrwavudSAWeyGQxHyt4Mp 7rzvhvGbC7c69p6BuAERLffsJn7IW4eC6qs49Rx4bA3NrsltyGfRqHpY2CELSMBB XFZ8rObc6/XhdDQwQr55t6Kidfi2VLMthHNMhlkLPqAcYKwZSL2crdbbQH3B+mvG 416aejEFccaAY2/yMGWm1U1NwwSMUaH+B4haTPQ/kKK6JqbAcrhp8oHVr3/aDPui GiQbvDvGf2eD264WkriAorQsCr/PkC2vecNJ+YcF6xnXaBS7kWYdsEeM1qdQMHI= =GaXf -----END PGP SIGNATURE----- ------enig2XUWEPPMKKNRKNTIPQDGQ--