Re: [Libvirt-cim] Re: XenFV on Pegasus Test Run Summary for Sep 11 2008
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(a)linux.vnet.ibm.com