Deepti B Kalakeri wrote:
Kaitlin Rupert wrote:
FAIL Test Summary: VirtualSystemManagementService - 14_define_sys_disk.py: FAIL The above tc is failing because of the the missing VirtualDevice field in the DiskRASD passed to DefineSystem(). The net, disk, proc, mem RASD properties passed to the DefineSystem() in this tc are obtained by the association of AC with SettingsDefineCapabilities. With the F9 rpm the VirtualDevice field in the DiskRASD is not set and hence the DefineSystem() throws an error. The tc passes when we include rasd['VirtualDevice'] field to contain appropriate VirtualDevice value 'hda' in case [KVM] of F9 rpm.
I have a doubt here, the changes to throw an error on Missing VirtualDevice field was included in the modifications made to the patch with revision 681 "Remove the default implied VirtualDevice on DiskRASD", but the changes included in the F9 rpm are upto 613. Can you let me know upto which changeset does the F9 rpm cover?
This is because the F9 rpm has additional patches applied to it. The last rpm update we did, we added the DiskRASD patch (along with a few others).
You can tell patches have been applied, because the revision number is 613+ instead of 613.
This makes branching the test difficult because you cannot rely on the revision number alone.
What you can do is check the changeset value. In const.py, you can designate the change set as the F9 changeset. This will allow you to branch tests appropriately. Can you elaborate here more, I did not get your point here.
get_provider_version() returns the changeset number. So in const.py, you can do: f9_changeset = "1fcf330fadf8+" When you need to branch, you can do: if changeset == const.f9_changeset: #Handle F9 case here It's not a very clean solution, but there's not a very easy way of telling what patches have been applied (unless you look at the rpm spec file, which would be out of the scope of cimtest). -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com