
Deepti B. Kalakeri wrote:
# HG changeset patch # User Deepti B. Kalakeri <deeptik@linux.vnet.ibm.com> # Date 1229602962 28800 # Node ID ff966617a775d47376459a69aca191f5367874dd # Parent adfa38df8c3b9600ff08796631c0eae7d3249ffe [TEST] Fixing 41_cs_to_settingdefinestate.py tc of CS to work with the latest libvirt-cim changes.
Libvirt-cim now supports GraphicsRASD for revision >=725 and InputRASD >= 746, hence updating/fixing the tc to accomodate these changes.
Tested with KVM on F9 , Xen/KVM with current sources.
Signed-off-by: Deepti B. Kalakeri <deeptik@linux.vnet.ibm.com>
diff -r adfa38df8c3b -r ff966617a775 suites/libvirt-cim/cimtest/ComputerSystem/41_cs_to_settingdefinestate.py
- # Verifying that the in_vssdc_list contains 4 entries one each for mem rasd, - # network rasd, processor rasd and disk rasd. - exp_len = 4 + # Verifying that the in_vssdc_list contains + # 4 entries one each for mem rasd, network rasd, processor rasd and + # disk rasd for libvirt-cim revision < 725 + # 5 entries one each for mem rasd, network rasd, processor rasd and + # disk rasd, graphics rasd for libvirt-cim revision >= 725 and < 746 + # 6 entries one each for mem rasd, network rasd, processor rasd and + # disk rasd, graphics rasd, input rasd for + # libvirt-cim revision >= 746 + curr_cim_rev, changeset = get_provider_version(virt, server) + if curr_cim_rev < libvirt_graphics_changes: + exp_len = 4 + elif curr_cim_rev >= libvirt_graphics_changes and \ + curr_cim_rev < libvirt_input_dev_changes: + exp_len = 5 + elif curr_cim_rev >= libvirt_input_dev_changes: + exp_len = 6 if check_len(an, in_vssdc_list, qcn, exp_len) != PASS: vsxml.destroy(server) return FAIL
I think this little bit of logic is confusing. I recently updated SettingsDefine/01_forward.py and SettingsDefine/02_reverse.py with an improved way of getting the RASD and device instances. I would suggest looking at that test, and using the enum_dev() and possibly the enum_rasds() functions to generate you instance lists. I think this would reduce the amount of code and possibly reduce the number of times you need to branch the test. This test is pretty old, so I think it's worth updating it some. Thoughts? -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com