Kaitlin Rupert wrote:
>> =================================================
>> 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
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.