Re: [Qemu-devel] [PATCH 13/14] qemu-nbd: Add --list option

[Eric Blake <eblake@redhat.com>]

On 12/7/18 10:49 AM, Vladimir Sementsov-Ogievskiy wrote:

>>>> $ qemu-nbd -L
>>>> exports available: 1
>>>>     export: ''
>>>>      size:  65536
>>>>      flags: 0x4ed ( flush fua trim zeroes df cache )
>>>>      min block: 512
>>>>      opt block: 4096
>>>>      max block: 33554432
>>>>      available meta contexts: 1
>>>>       base:allocation
>>>
>>> don't you plan to bind this all to QAPI and expose in json?
>>
>> No. As explained above, QAPI is very much centered on per-BDS actions, while this action is a per-server action (where many servers have only one export, but it is also possible to have a server with 0 exports or a plurality of exports).  I _can't_ fit this into query-block's ImageInfo details about a block device, because we don't have a way of stating 'connect to this arbitrary server, create an unspecified number of block devices, tell me about each of them, and then throw them all away because we only wanted the info about what the server made available'. The same is true for gluster or other remote access block devices - the QMP commands pre-suppose you already know WHICH specific resource you are accessing, rather than providing a way for you to query the remote server about ALL resources available but without actually selecting those resources.
>>
>> I'm open to ideas about a new QMP command to do such a query, but who would be the client?  A management app that wants to hotplug a new NBD device to a running guest can run 'qemu-nbd --list' just as easily as they could run a new QMP command to learn what the server is offering. Without a strong reason of a client that would need this in QMP, I don't see the point in adding it to the qemu binary.
> 
> I didn't mean QMP. For example, QAPI struct ImageCheck is used only in qemu-img, to format output.
> Anyway, creating a struct in QAPI for something we want to export is a good thing, I think.

Oh, I see where you're going with this. Just as 'qemu-img info' has 
routines to pretty-print a QAPI structure (and thus adding ImageInfo to 
the .json files automatically gets output in HMP without any additional 
work), you're suggesting that NBDExportInfo be converted into a QAPI 
struct, even if it won't be tied to QMP, in order to make the output 
more programmatic instead of manual effort.  I'll have to play with 
that, although it might be a separate series on top of this.

> Also, if, as you said, some management app wants to query this information, again strictly
> defined data + json output should be a good option. And, if there would be such users, we'll
> need to track compatibility of exported structure between qemu versions and this is easier
> with QAPI defined structure.
> 
> And then, defined structure may be then (at least partly) shared with ImageInfoSpecificNBD.
> 
> And if we will need at some point a qmp command like query-nbd-server, to get same information through
> current qmp-connection, not running additional nbd-client, it would be a simple thing to do.

If we ever need future extensions, we'll want to have QAPI structs in 
place. But whether we implement the QAPI structs now, or at the time of 
the future extension, is an engineering tradeoff (how much technical 
debt are we incurring by not doing it now; and how likely are we to ever 
want the future extension).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org