Eric Blake <eblake@xxxxxxxxxx> 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 mail that is related to the topic - > feature detection of whether dump-guest-memory supports paging: > https://lists.gnu.org/archive/html/qemu-devel/2013-04/msg04613.html > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
