Eric Blake writes:
> On 04/23/2013 08:45 AM, Juan Quintela wrote:
>>
>> * 1.5 pending patches (paolo)
>> anthony thinks nothing big is outstanding
>> rdma: not probably for this release, too big change on migration
>> cpu-hotplug: andreas expect to get it for 1.5
>>
>>
>> * What can libvirt expect in 1.5 for introspection of command-line support?
>> command extensions? libvirt want then
>> * What are the rules for adding optional parameters to existing QMP
>> commands? Would it help if we had introspection of QMP commands?
>> what are the options that each command support.
>>
>> command line could work for 1.5
>> if we got patches on the next 2 days we can get it.
>
> Goal is to provide a QMP command that provides JSON representation of
> command line options; I will help review whatever is posted to make sure
> we like the interface. Anthony agreed the implementation should be
> relatively straightforward and okay to add after soft freeze (but must
> be before hard freeze). Libvirt has some code that would like to make
> use of the new command-line introspection; Osier will probably be the
> first libvirt developer taking advantage of it - if we can swing it,
> we'd like libvirt 1.0.5 to use the new command (libvirt freezes this
> weekend for a May 2 release).
>
>> rest of introspection need 1.6
>> it is "challenging"
>> we are interesting into feature introspection
>> and comand extensions?
>> one command to return the schema?
>
> Anthony was okay with the idea of a full JSON introspection of all QMP
> commands, but it is probably too big to squeeze into 1.5 timeframe.
> Furthermore, while the command will be useful, we should always be
> thinking about API - having to parse through JSON to see if a feature is
> present is not always the nicest interface; when adding a new feature,
> consider improving an existing query-* or adding a counterpart new
> query-* command that makes it much easier to tell if a feature is
> available, without having to resort to a QMP introspection.
Ack.
One of the problems with using schema introspection for feature
detection is that there isn't always a 1-1 mapping. You can imagine
that we have an optional parameter that gets added to a structure and is
initially tied to a specific feature but later gets used by another
feature.
If a distro backports the later and not the former, but a management
tool uses this field to probe for the former feature, it will result in
a false positive.
That's why a more direct feature negotiation mechanism is better IMHO.
Regards,
Anthony Liguori
>
>> if we change a command, how we change the interface without
>> changing the c-api?
>
> c-api is not yet a strong consideration (but see [1] below). Also,
> there may be ways to design a C api that is robust to extensions (but
> that means designing it into the QMP up front when adding a new
> command); there has been some list traffic on this thought.
>
> More importantly, adding an optional parameter to an existing command is
> not okay unless something else is also available to tell whether the
> feature is usable - QMP introspection would solve this, but is not
> necessarily the most elegant way. For now, while adding QMP
> introspection is a good idea, we still want case-by-case review of any
> command extensions.
>
>>
>> we can change "drive_mirror" to use a new command to see if there
>> are the new features.
>
> drive-mirror changed in 1.4 to add optional buf-size parameter; right
> now, libvirt is forced to limit itself to 1.3 interface (no buf-size or
> granularity) because there is no introspection and no query-* command
> that witnesses that the feature is present. Idea was that we need to
> add a new query-drive-mirror-capabilities (name subject to bikeshedding)
> command into 1.5 that would let libvirt know that buf-size/granularity
> is usable (done right, it would also prevent the situation of buf-size
> being a write-only interface where it is set when starting the mirror
> but can not be queried later to see what size is in use).
>
> Unclear whether anyone was signing up to tackle the addition of a query
> command counterpart for drive-mirror in time for 1.5.
>
>>
>> if we have a stable c-api we can do test cases that work.
>
> Having such a testsuite would make a stable C API more important.
>
>>
>> Eric will complete this with his undrestanding from libvirt point of
>> view.
>
> Also under discussion: the existing QMP 'screendump' command is not
> ideal (not extensible, doesn't allow fd passing, hard-coded output
> format). This was used as an example command that should not be
> extended until we have appropriate feature detection in place; probably
> easier to add a new QMP command than to add parameters to the existing
> one. At any rate, we're late enough that 'screendump' probably won't be
> improved in 1.5, so we have the full 1.6 cycle to get it right.
>
> Not on the phone call, but a recent mai
