Re: [Qemu-devel] RFC: Full introspection support for QMP

[Eric Blake]

On 05/23/2013 07:52 AM, Anthony Liguori wrote:
>> libvirt already knows how to use features. It must know it, just parsing
>> the schema doesn't automagically give you libvirt code, so someone must
>> have coded the libvirt side of things. The interesting part is whether a
>> given interface is available on this specific qemu binary.
> 
> Take 'drive-mirror' as an example.  The format parameter is a string.
> You can't tell what valid arguments are for this parameter with
> introspection.
> 
> You can certainly say that we can make this an enum, and do
> introspection on the enums, but that only works because it's a string.

Introspection on an enum and on optional parameters are both nice ways
of learning whether libvirt can expect success when passing a particular
use of that enum or option extension.  That does not cover ALL ways that
features are added, but it sure covers a lot, which makes it a nice
reusable framework for learning about quite a few features.  Yes, I
suspect we will still have to add some query-* commands along the way
for features that aren't quite discernible solely from introspection, or
even where a query can give the information in a nicer format than
crawling through several layers of type information, but I see these as
orthogonal, not competing, so that is not a reason to exclude either
approach from being added to QMP.

> 
> The same thing can apply to integer arguments.  If a new value becomes
> valid that previously was rejected, then libvirt probably needs to be
> able to figure that out.

Changing an integer range is a bit harder; but again, with PROPER
introspection, you can include range information alongside type information.

> 
>>>> It also makes the schema totally useless. If you can't use it to tell
>>>> which commands this qemu can execute and which it can't,
>>>
>>> query-commands serves that purpose.
>>
>> It solves a subset of this problem. Optional fields can be added as
>> arguments or to returned structs, enums can be extended, and so far
>> we're having a hard time making use of it because the client can't
>> discover it.
> 
> Ack.

Yes, this is the primary motivating factor behind asking for
introspection at the moment.

> 
>>>> We can have hundreds of individual query commands like you suggest
>>>> (query-qcow2-creation-option-values, yay!) or we do the modularity
>>>> thing and the schema introspection properly and make it dynamic. I
>>>> prefer the latter.
>>>
>>> Let's consider a real example.  It sounds like you have something in
>>> mind, can you be more specific?
>>
>> Not a very specific one, it's just that the more I discuss about things
>> like blockdev-add, the more I get the impression that there is an awful
>> lot of information to query. Each image format can provide different
>> options, for creating images and for opening them, and some of them may
>> be enums that could be extended and whose values must be queried etc.
> 
> But is this specific to blockdev-add?  The supported image formats are
> global and apply to multiple commands.
> 

But that still argues that having a dynamic approach to learning "what
formats are supported, and what options does a given format provide
beyond the basics".

> Also, do we need to expose which formats are read-only vs. read-write?
> That wouldn't be part of the schema I would think.

True, a pure 'enum' in qapi-schema.json wouldn't expose which types are
read-only vs. read-write, so that argues for a query-* command for
learning details about the various block formats.  Once you have a
query-* command (which is dynamic), then having a non-dynamic 'enum' in
the schema expressing all known types (whether loaded or not) is
reasonable, where the query command then returns the subset of known
formats that are actually loaded and what additional features each
format comes with.

> 
>> Schema introspection allows you to have one single way to check for all
>> optional fields, enum values, union branches. The other way is to have a
>> separate command for each of them.
> 
> Yes, my only worry is that the schema probably doesn't contain all of
> the information that something like libvirt needs.

I don't think that schema introspection can provide everything, but it
can sure provide a lot, and minimize the number of cases where we
actually need a query-* command.

> 
>> Basically instead of query-enum(Qcow2PreallocationType) you get
>> query-qcow2-prellocation-types(). You can imagine how the set of
>> commands grows once you start doing things this way.
>>
>> When I discussed with Eric (who is one of the few actual consumers of
>> the API), he preferred introspection of a dynamic schema as well,
>> compared to many separate query-* commands.
> 
> I'm not opposed to schema introspection even if it's used for this type
> of use-case.
> 
> But I don't think it's a complete solution.  We should think about what
> the use-cases are and make sure we have a solution that addresses them.

Agreed.

> 
> None of that should hold back schema introspection...

Agreed.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature