import sys -from CimTest import Globals from XenKvmLib.const import do_main -from XenKvmLib.test_doms import destroy_and_undefine_all from XenKvmLib import assoc from XenKvmLib import vxml
Change this to XenKvmLib.vxml import get_class
+ for rasd in assoc_info: + guest, dev, status = parse_instance_id(rasd['InstanceID']) + if status != PASS: + logger.error("Unable to parse InstanceID: %s", rasd['InstanceID']) + return status + + if guest != test_dom: + continue
Instead of a continue here, this should throw an error.
VirtualSystemSettingDataComponent should only return RASDs that correspond to a give VSSD. And a VSSD instance can only represent one guest.
This is a mistake I made in SettingsDefine/02_reverse.py, which is the test I told you to reference. Sorry for the error here! I'll send a patch to fix this bug.
Really, we don't need to do this check at all. When I was re-writing SettingsDefine/02_reverse.py, I was thinking that it is a good idea to verify that the RASDs match the guest we're testing.
But really, if VirtualSystemSettingDataComponent returns the wrong instances, that's something the VirtualSystemSettingDataComponent related tests should find. This test should be concerned with verifying the RASD properties, it shouldn't be concerned with also verifying the output of VirtualSystemSettingDataComponent.
But it's still a valid check to have. So you can leave it in or remove it. Either way is fine by me. =) Yesthis is true. For now I have left the above check as it is, since the VSSDC test cases does not verify this as of now.
+ + logger.info("Verifying: %s", rasd.classname) + exp_rasd = rasds[rasd.classname] + for item in rasd.items(): + key = item[0] + exp_val = eval('exp_rasd.' + key) + ret_rasd_val = rasd[key] + if ret_rasd_val == exp_val: + status = PASS
Will compare_all_prop() work for this? When we spoke, I said that compare_all_prop() should be phased out once the association related calls return the same object type as the enumeration related calls.
However, since the the return types of the enumeration calls and the association calls don't match yet, I'd rather compare_all_prop() be used instead of duplicating the code here. When it comes time to remove compare_all_prop(), it's easier to replace the function name than it is to replace an entire code block.
Sorry for the confusion there. I thought since we plan to remove the compare_all_prop() sometime and since it is used in very few place, I wrote this above piece of code in
Kaitlin Rupert wrote: the tc itself. I have changed the above to use compare_all_prop().
else: - status = 1 - if status != 0 or proc_status != 0 or net_status != 0 or \ - disk_status != 0 or mem_status != 0 : - logger.error("Mistmatching association values" ) - status = 1 - except Exception, detail : - logger.error("Exception in assoc_values function: %s" % detail) - status = 1 - - return status - + logger.info("Got %s instead of %s", ret_rasd_val, exp_val) + status = FAIL + break + + if status != PASS: + logger.error("RASD with id %s not returned", exp_rasd.InstanceID)
This message is misleading.. because you verify all the properties. So even if the InstanceID matches, one of the other properties could be different. I would use a more generic message to indicate that a matching RASD wasn't found.
The providers shouldn't return more than one RASD with the same InstanceID. But it's possible it could happen in some kind of odd error condition.
virt_xml = vxml.get_class(virt) if virt == 'LXC': cxml = virt_xml(test_dom) else: cxml = virt_xml(test_dom, mem=test_mem, vcpus = test_vcpus, - mac = test_mac, disk = test_disk) - ret = cxml.create(options.ip) + mac = test_mac) + + ret = cxml.create(server)
Can you change this to define() and cim_start().
Should have noticed this before itself. Changed the tc to use define and start now. Thanks and Regards, Deepti.