On 02/21/2013 09:19 PM, Eduardo Habkost wrote:
On Thu, Feb 21, 2013 at 01:49:56PM +0800, Yiqiao Pu wrote:
On 02/21/2013 05:48 AM, Eduardo Habkost wrote:
Unit test for the response parsing included.
Signed-off-by: Eduardo Habkost <[email protected]>
---
virttest/qemu_monitor.py | 45 +++++++++++++++++++++++++++++++++++++++
virttest/qemu_monitor_unittest.py | 21 ++++++++++++++++++
2 files changed, 66 insertions(+)
create mode 100644 virttest/qemu_monitor_unittest.py
diff --git a/virttest/qemu_monitor.py b/virttest/qemu_monitor.py
index 08ce708..4348128 100644
--- a/virttest/qemu_monitor.py
+++ b/virttest/qemu_monitor.py
@@ -242,6 +242,51 @@ class Monitor:
raise NotImplementedError
+ # Methods that should work on both classes, as long as human_monitor_cmd()
+ # works:
+
+ re_numa_nodes = re.compile(r"^([0-9]+) nodes$", re.M)
+ re_numa_node_info = re.compile(r"^node ([0-9]+) (cpus|size): (.*)$", re.M)
+ @classmethod
+ def parse_info_numa(cls, r):
+ """
+ Parse 'info numa' output
+
+ See info_numa() for information about the return value.
+ """
+
+ nodes = cls.re_numa_nodes.search(r)
+ if nodes is None:
+ raise Exception("Couldn't get number of nodes from 'info numa'
output")
+ nodes = int(nodes.group(1))
+
+ data = [[0, set()] for i in range(nodes)]
+ for nodenr,field,value in cls.re_numa_node_info.findall(r):
+ nodenr = int(nodenr)
+ if nodenr > nodes:
+ raise Exception("Invalid node number on 'info numa' output:
%d", nodenr)
+ if field == 'size':
+ if not value.endswith(' MB'):
+ raise Exception("Unexpected size value: %s", value)
+ megabytes = int(value[:-3])
Now qmp monitor can not support 'info numa'.
This should work with both monitor types, because I'm using the
human_monitor_cmd() method.
So this command is
executed though the human monitor interface. So this format analyse
function actually analyse the data in human monitor output format. So
maybe when qmp monitor support numa query this unit and format may
changes.
It may change, but when it happen we will need a completely new parser,
anyway.
So how about using a function for the unit convert. We have
a function named standard_value in utils_misc in our tree. It looks
like this:
def standard_value(value_str, standard_unit="M", base="1024"):
"""
return the value based on the standard unit given
@param value_str: a string include the data and unit
@param standard_unit: the unit of the result based
@param base: the base between two adjacent unit. Normally could be 1024
or 1000
"""
I will push it to upstream. And how about use it to handle the size part?
It sounds great. I was actually planning to return size in bytes instead
of MB, but it would make my test case/config more complex. Using the
above function, I could use sizes in bytes, but keep the test
code/config simple.
+ data[nodenr][0] = megabytes
+ elif field == 'cpus':
+ cpus = set([int(v) for v in value.split()])
+ data[nodenr][1] = cpus
+ data = [tuple(i) for i in data]
+ return data
+
+ def info_numa(self):
+ """
+ Run 'info numa' command and parse returned information
+
+ @return: An array of (ram, cpus) tuples, where ram is the RAM size in
+ MB and cpus is a set of CPU numbers
+ """
+ r = self.human_monitor_cmd("info numa")
We already have a function info() which can handle all kinds of query
operation in both human monitor and qmp monitor. So how about use
that directly?
The QMP class info() method is unpredictable and unreliable (for my use
case): it returns different results depending on the availability of a
"query_*" QMP command. It would make my test break if one day QMP
introduces a "query-numa" command, and I don't want that to happen.
Understand your point. But if QMP support query-numa command one day, we
also need test them in the numa test cases. So if that happen we need
update the numa case to support it anyway.
+ return self.parse_info_numa(r)
+
And most of the functions in Monitor class only use for sending out
the command line and getting the results without data parse. So maybe
we should give this function a better name to make it differently
with those just though out the results?
I don't understand what you mean. The method names look very clear to
me, and I don't see why they should have a different name just because
they are generic and live in the base Monitor class.
I mean most of the functions that have the similar name with the monitor
command now is only used for delivering the command line and results
directly, but not analyse the results and give a certain format results.
When we call this function we should keep this in mind that the
info_numa is not return the results directly but will return "An array
of (ram, cpus) tuples". It is different with other functions like
getfd() and etc. in Monitor class. So maybe something like
info_numa_formatted() is better for this kind of functions?
(The fact that there were no existing methods independent of
monitor-type in the base Monitor class actually surprised me. There are
lots of useful methods that could be in the base class, because QMP is
also able to handle HMP commands if necessary.)
Although QMP can handle HMP commands but in testing we should try to use
QMP commands directly if they are exist. Otherwise the testing for QMP
code should have less code coverage and which means we may miss bugs in
that part of code.
+
class HumanMonitor(Monitor):
"""
Wraps "human monitor" commands.
diff --git a/virttest/qemu_monitor_unittest.py
b/virttest/qemu_monitor_unittest.py
new file mode 100644
index 0000000..8e1d373
--- /dev/null
+++ b/virttest/qemu_monitor_unittest.py
@@ -0,0 +1,21 @@
+import unittest
+from qemu_monitor import Monitor
+
+class InfoNumaTests(unittest.TestCase):
+ def testZeroNodes(self):
+ d = "0 nodes\n"
+ r = Monitor.parse_info_numa(d)
+ self.assertEquals(r, [])
+
+ def testTwoNodes(self):
+ d = "2 nodes\n" + \
+ "node 0 cpus: 0 2 4\n" + \
+ "node 0 size: 12 MB\n" + \
+ "node 1 cpus: 1 3 5\n" + \
+ "node 1 size: 34 MB\n"
+ r = Monitor.parse_info_numa(d)
+ self.assertEquals(r, [(12, set([0, 2, 4])),
+ (34, set([1, 3, 5]))])
+
+if __name__ == "__main__":
+ unittest.main()
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
