Re: [Qemu-devel] [Qemu-block] [PATCH v11 07/31] iotests.py: Add node_info()

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2993 bytes --]

On 08.10.18 21:59, John Snow wrote:
> 
> 
> On 10/08/2018 03:57 PM, Max Reitz wrote:
>> On 08.10.18 21:34, John Snow wrote:
>>>
>>>
>>> On 10/05/2018 07:39 PM, Max Reitz wrote:
>>>> This function queries a node; since we cannot do that right now, it
>>>> executes query-named-block-nodes and returns the matching node's object.
>>>>
>>>> Signed-off-by: Max Reitz <mreitz@redhat.com>
>>>> ---
>>>>  tests/qemu-iotests/iotests.py | 7 +++++++
>>>>  1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
>>>> index 5c45788dac..604f200600 100644
>>>> --- a/tests/qemu-iotests/iotests.py
>>>> +++ b/tests/qemu-iotests/iotests.py
>>>> @@ -465,6 +465,13 @@ class VM(qtest.QEMUQtestMachine):
>>>>                  else:
>>>>                      iotests.log(ev)
>>>>  
>>>> +    def node_info(self, node_name):
>>>> +        nodes = self.qmp('query-named-block-nodes')
>>>> +        for x in nodes['return']:
>>>> +            if x['node-name'] == node_name:
>>>> +                return x
>>>> +        return None
>>>> +
>>>>  
>>>>  index_re = re.compile(r'([^\[]+)\[([^\]]+)\]')
>>>>  
>>>>
>>>
>>> Reviewed-by: John Snow <jsnow@redhat.com>
>>>
>>> Do we ever want to revisit the idea that our API should not do any
>>> pre-filtering and that it's always up to the client to do so?
>>
>> I mean we certainly want to revisit the idea that we should have a
>> proper query API.
>>
>> But what exactly do you mean by pre-filtering?
>>
>> Max
>>
> 
> i.e. applying selection criteria before responding to the query. e.g.,
> by looking for matches on node-name.
> 
> (Did I use i.e. and e.g. right?)

So you mean our API should do pre-filtering at the request of the client
and the client shouldn't be fed all nodes and then have to do
post-filtering?

Well, I certainly think we want a query command that doesn't return all
nodes.  I personally would prefer something that only returns a single
node in the graph and its relationships, although I'm not sure whether
that is very efficient.  Maybe something like inverse blockdev-add, were
the user can specify a depth on how deep references should be expanded.

Overall, I'm of the impression we want to have blockdev-reopen first so
that we have a good idea of the type of information we want to report
for a node; that being its node options, first and foremost.  Probably
some stats as well, though.

Max


(The i.e. looks weird because you're not expanding a thought you've just
given, but you're actually responding to my question.  It's like saying
"I want feature A." -- "We can do that, do you have any other remarks?"
-- "And I want B, too."  So I would have started either with "e.g." (if
you think there are other things that could be meant by pre-filtering),
or by e.g. "I thought of".  Probably the latter, since that is how I
interpreted your "i.e.".)

((Did I use the semicolon correctly?))


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]