================================================= FAIL Test Summary: ComputerSystem - 23_suspend_suspend.py: FAIL The above tc passed when run manually.
Do you know what caused the guest to fail to start? Does the test always fail during bulk run?
It sounds like a guest from a previous test isn't being cleaned up properly. This will need to be fixed.
================================================= XFAIL Test Summary: ComputerSystem - 32_start_reboot.py: XFAIL ComputerSystem - 33_suspend_reboot.py: XFAIL ResourceAllocationFromPool - 05_RAPF_err.py: XFAIL The above RAFP tc is written to verify that RAFP returns appropriate error when a non-existing bridge or networkpool is used in defining a guest. But, the tc now XFAIL's because it returns a valid RAFP record.
This should be a failure and not an XFAIL. There's no bug number associated with the failure, so the logic of try_assoc() is incorrectly returning an XFAIL. Yes it should return FAIL when a bug no is not specified ( implying that
Kaitlin Rupert wrote: this is a failure and no bug exist against the association being tried.)
This is due to the use of the cim_define() in the test case. Before calling the cim_define() we make necessary changes to the XML configuration to reflect the invalid bridge/networkpool name. But when we use the cim_define() function we do not have any means where we can use the invalid networkpool name or bridgename.
cim_define() uses the VSSD and various RASD objects that belong to the instance of the VirtCIM class that is created. Instead of using modify_net_name(), the invalid network name should be passed in when the instance of VirtCIM is initialized.
Yes, I agree with you that we should make use of the Providers supplied functions, like DefineSystem() as much possible. I had tried supplying the networkpoolname/bridgename in the VirtXML, and it works fine till then to get an XML which contains invalid networkpool/bridgename. But when we call cim_define() we dont make use of the XML generated till then. In cim_define() we make use of VSSD, various RASD and I did not find a relevant field in NetRASD which could be used for supplying the invalid name info. Here is the NetRASD fields. -Caption -Description -InstanceID -ElementName -ConfigurationName -ChangeableType -ResourceType=10 -OtherResourceType -ResourceSubType -PoolID -ConsumerVisibility -HostResource -AllocationUnits -VirtualQuantity -Reservation -Limit -Weight -AutomaticAllocation -AutomaticDeallocation -Parent -Connection -Address -MappingBehavior -NetworkType I tried using ElementName, but was not much help. Can you suggest how or which of the VSSD, RASD fields could be used to supply the networkpool/birdge name. Thanks and Regards, Deepti.
Hence the DefineSystem() in the cim_define() goes ahead to define a guest with the valid networkpoolname and RAFP returns a record, which is against the test case. I ran the tc for Xen/XenFV and the tc fails there as well. Can we revert back to the define() [which used virsh to define the guest], which initially existed in the tc ??
If we use the virsh define, we're testing the virsh define call - the provider DefineSystem() is not being tested in this case. Wherever possible, we should be using DefineSystem() so that the provider stack is tested.