[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 2/3] Add migrate_incoming
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH v3 2/3] Add migrate_incoming |
Date: |
Fri, 20 Feb 2015 18:57:16 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
Eric Blake <address@hidden> writes:
> On 02/20/2015 01:18 AM, Markus Armbruster wrote:
>> I'd like Eric's opinion on on encoding configuration tuples as URIs
>> rather than JSON in QMP.
>>
>
>>> +{ 'command': 'migrate-incoming', 'data': {'uri': 'str' } }
>>> +
>>> # @xen-save-devices-state:
>>> #
>>> # Save the state of all devices to file. The RAM and the block devices
>>
>> Eric, what's your take on this?
>>
>> The general rule in QMP is "no ad hoc encoding of tuples in strings, use
>> JSON objects instead".
>
> Yes, it would be nice to be type-safe, and have a QAPI union with a
> discriminator of different URI types along with appropriate accompanying
> data. But it is also new code (both in qemu to parse it, and in libvirt
> to generate it), and we already have existing code that knows how to
> generate the string-encoded tuple for the -incoming command line
> argument that can be reused as-is with the new QMP command as proposed.
> So even though it is less safe, I'm okay with this particular command
> using an overloaded string argument.
>
> Down the road, if we WANT to add type-safety, we can make this command
> take an anonymous union, where a 'str' value is the compact old style,
> and where a dictionary value is the new discriminated union style. So
> we aren't completely locked into non-type-safe string forever, but we
> probably won't add a type-safe variant until (if) we ever add a new
> migration format that just looks too ugly as a URI based on the
> parameters it requires.
I can accept this, but I want the rationale in a comment, so this
exception to the QMP rule serves less well as bad example.
[Qemu-devel] [PATCH v3 3/3] Document -incoming options, Dr. David Alan Gilbert (git), 2015/02/19
Re: [Qemu-devel] [PATCH v3 0/3] -incoming defer, Michael S. Tsirkin, 2015/02/22
Re: [Qemu-devel] [PATCH v3 0/3] -incoming defer, Stefan Hajnoczi, 2015/02/23