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.
>
> 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.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
