[Libvirt-cim] Re: XenFV on Pegasus Test Run Summary for Sep 11 2008

[Kaitlin Rupert]

> The above tc will pass if we revert back to the changes done using 
> "[PATCH 4 of 6] [TEST] Make network related changes to VSMS tests".
>> VirtualSystemManagementService - 08_modifyresource.py: FAIL
>>

>
> 
> If we see above we can find two disk information in the devices section, 
> well the first disk information is valid and belongs to the 
> rstest_domain which is created before modfications.

> I tried looking into if the previous test case added this info, but it 
> did not seem like.

The test VSMS 06_addresource.py adds an additional disk device.

> I tried to give some delay before and after the ModifyResourceSetting() 
> call, to see it is caching issue, but it did not help either.
> Can you help to go about this problem?
> 

This is caused by the caching issue.  What's happening here is that by 
the time 06_addresource.py is done running, it has defined a guest named 
rstest_domain and added an additional disk to the guest. 
06_addresource.py then undefines that guest.

However, because the test suite runs so fast, when 08_modifyresource.py 
calls ModifyResources(), the provider gets the XML of the stale guest 
(not the new XML defined by 08_modifyresource.py because the old guest 
is still cached).  So we're picking up stale data.

The likelihood of a user hitting this issue is minimal.  Both of these 
tests need to be updated to use cim_define() / cim_start() as needed.

-- 
Kaitlin Rupert
IBM Linux Technology Center
kaitlin at linux.vnet.ibm.com