On 03/08/2012 10:06 PM, Alex Jia wrote: > On 03/08/2012 10:23 PM, Chris Evich wrote: >> On 03/08/2012 01:33 AM, Alex Jia wrote: >>> On 03/08/2012 11:52 AM, guyanhua wrote: >>>> This patch adds three test cases for "virsh capabilities" command. >>>> >>>> Use three cases:(1) Call virsh capabilities >>>> (2) Call virsh capabilities with an unexpected option >>>> (3) Call virsh capabilities with libvirtd service stop >>>> >>>> Signed-off-by: Gu Yanhua<[email protected]> >>>> --- >>>> client/tests/libvirt/tests/virsh_capabilities.py | 51 >>>> ++++++++++++++++++++++ >>>> 1 files changed, 51 insertions(+), 0 deletions(-) >>>> create mode 100644 client/tests/libvirt/tests/virsh_capabilities.py >>> How to make sure output information of virsh capabilities are correct? >>> for example,<cpu>,<power management>,<topology>,<guest> XML block >>> information etc. >> Good point, I agree some minimal level of checking should be done. My >> suggestion would be to keep it very simple, maybe use xml.dom.minidom to > Chris, agree with you, we should check some important points at least. >> check for the top-level tags, and call that 'good enough'. I don't >> think we want to be too pedantic about checking correctness because it >> could make maintenance a pain in the future. Heck, maybe just a few > But, I don't think so, it's our job to ensure that virsh commands > correct and > available, if we can't make sure it's completely correct, for example, > the current > hyperviosr is xen , however, virsh capabilities says domain type='kvm' > and 'qemu'. > so we still need to check some important points although they probably > are too > pedantic :-)
Yes, I think we're mostly on the same page, it's a balance. My concern over "too much" correctness checking, is to avoid writing ourselves into a maintenance headache if the output schema changes, libvirt is running on a unknown host type (by today's standards), or new capabilities are added to libivrt itself. I think "correct" can mean, the output XML parses w/o throwing exceptions, and it contains some minimal expected capabilities info. (and not likely to change much between versions or across hosts). For example, check that Host has a non-empty UUID tag & data value, CPU arch data != "Orangutan", and there's at least one CPU feature tag (w/o caring about the value). Sound good? -- Chris Evich, RHCA, RHCE, RHCDS, RHCSS Quality Assurance Engineer e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214 _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
