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. > 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
signature.asc
Description: OpenPGP digital signature
