KVM test report on Fedora 9
Distro: Fedora 9 Beta Kernel: 2.6.25-0.121.rc5.git4.fc9 Libvirt: 0.4.1-7.fc9 CIMOM: 2.7.0-6.fc9 PyWBEM: 0.6-1 libcmpiutil: 0.3-1.fc9 libvirt-cim: 0.3-4.fc9 cimtest: changeset-76 =========FAIL============= AllocationCapabilities - 02_alloccap_gi_errs.py: FAIL "Requested Object could not be found." vs. "Instance not found." error string issue. The return code is correct. [Known Issue] ComputerSystemIndication - 01_created_indication.py: FAIL Exception : Authentication (or request) Failed! Previous tests were always on sfcb. Anyone has a successful experience on pegasus for indication? ElementAllocatedFromPool - 03_reverse_errs.py: FAIL exp: ERR_NOT_FOUND(6) - No such instance ret: ERR_FAILED(1) - Invalid InstanceID or unsupported pool type ElementConforms - 02_reverse.py: FAIL Binary rpm provider returns CIM_ERR_INVALID_PARAMETER: KVM_ElementConformsToProfile on the following query: wbemain -ac KVM_ElementConformsToProfile 'http://u:p@host:5988/root/virt:KVM_ComputerSystem.CreationClassName="KVM_ComputerSystem",Name="domgst"' Same wbemcli command gets the correct results on another system using latest libvirt-cim tree (changeset 533). HostSystem - 02_hostsystem_to_rasd.py: FAIL MegaBytes vs. KiloBytes issue on RASD [Known Issue] NetworkPort - 03_user_netport.py: FAIL 'user' network type. [Known Issue] RASD - 01_verify_rasd_fields.py: FAIL RASD - 02_enum.py: FAIL Same as HostSystem.02 ReferencedProfile - 01_verify_refprof.py: FAIL Binary rpm provider gives 2 results on the following query: wbemein http://u:p@host:5988/root/interop:KVM_RegisteredProfile "CIM:DSP1042-SystemVirtualization-1.0.0" "CIM:DSP1057-VirtualSystem-1.0.0a" Same wbemcli command gets 5 results on changeset-533 tree on another system. "CIM:DSP1042-SystemVirtualization-1.0.0" "CIM:DSP1057-VirtualSystem-1.0.0a" "CIM:DSP1059-GenericDeviceResourceVirtualization-1.0.0" "CIM:DSP1045-MemoryResourceVirtualization-1.0.0" "CIM:DSP1081-VirtualSystemMigration-1.0" This leads to ReferencedProfile's 'ain' query gets only 2 results. ReferencedProfile - 02_refprofile_errs.py: FAIL Same as ReferencedProfile.01 ResourceAllocationFromPool - 03_forward_errs.py: FAIL exp: ERR_NOT_FOUND(6) - No such instance (wrong) - resource pool type mismatch ret: ERR_FAILED(1) - Invalid InstanceID or unsupported pool type ResourcePoolConfigurationService - 03_CreateResourcePool.py: FAIL ResourcePoolConfigurationService - 04_CreateChildResourcePool.py: FAIL ResourcePoolConfigurationService - 06_RemoveResourcesFromResourcePool.py: FAIL ResourcePoolConfigurationService - 07_DeleteResourcePool.py: FAIL ====FULL CIMTEST REPORT=PASS(70)=FAIL(18)=SKIP(34)=XFAIL(7)======= AllocationCapabilities - 01_enum.py: PASS AllocationCapabilities - 02_alloccap_gi_errs.py: FAIL ComputerSystem - 01_enum.py: PASS ComputerSystem - 02_nosystems.py: PASS ComputerSystem - 03_defineVS.py: PASS ComputerSystem - 04_defineStartVS.py: PASS ComputerSystem - 05_activate_defined_start.py: XFAIL Bug: 85769 ComputerSystem - 06_paused_active_suspend.py: XFAIL Bug: 85769 ComputerSystem - 22_define_suspend.py: PASS ComputerSystem - 23_suspend_suspend.py: SKIP ComputerSystem - 27_define_suspend_errs.py: SKIP ComputerSystem - 32_start_reboot.py: SKIP ComputerSystem - 33_suspend_reboot.py: SKIP ComputerSystem - 35_start_reset.py: SKIP ComputerSystem - 40_RSC_start.py: XFAIL Bug: 91410 ComputerSystem - 41_cs_to_settingdefinestate.py: SKIP ComputerSystem - 42_cs_gi_errs.py: PASS ComputerSystemIndication - 01_created_indication.py: FAIL ElementAllocatedFromPool - 01_forward.py: SKIP ElementAllocatedFromPool - 02_reverse.py: SKIP ElementAllocatedFromPool - 03_reverse_errs.py: FAIL ElementAllocatedFromPool - 04_forward_errs.py: XFAIL Bug: 88651 ElementCapabilities - 01_forward.py: PASS ElementCapabilities - 02_reverse.py: PASS ElementCapabilities - 03_forward_errs.py: PASS ElementCapabilities - 04_reverse_errs.py: PASS ElementCapabilities - 05_hostsystem_cap.py: PASS ElementConforms - 01_forward.py: PASS ElementConforms - 02_reverse.py: FAIL ElementConforms - 03_ectp_fwd_errs.py: XFAIL Bug: 92642 ElementConforms - 04_ectp_rev_errs.py: SKIP ElementSettingData - 01_forward.py: SKIP ElementSettingData - 03_esd_assoc_with_rasd_errs.py: SKIP EnabledLogicalElementCapabilities - 01_enum.py: PASS EnabledLogicalElementCapabilities - 02_elecap_gi_errs.py: PASS HostSystem - 01_enum.py: PASS HostSystem - 02_hostsystem_to_rasd.py: FAIL HostSystem - 03_hs_to_settdefcap.py: PASS HostSystem - 04_hs_to_EAPF.py: SKIP HostSystem - 05_hs_gi_errs.py: PASS HostSystem - 06_hs_to_vsms.py: PASS HostedDependency - 01_forward.py: SKIP HostedDependency - 02_reverse.py: SKIP HostedDependency - 03_enabledstate.py: SKIP HostedDependency - 04_reverse_errs.py: SKIP HostedResourcePool - 01_forward.py: PASS HostedResourcePool - 02_reverse.py: PASS HostedResourcePool - 03_forward_errs.py: PASS HostedResourcePool - 04_reverse_errs.py: PASS HostedService - 01_forward.py: PASS HostedService - 02_reverse.py: PASS HostedService - 03_forward_errs.py: PASS HostedService - 04_reverse_errs.py: PASS LogicalDisk - 01_disk.py: PASS LogicalDisk - 02_nodevs.py: PASS LogicalDisk - 03_ld_gi_errs.py: PASS Memory - 01_memory.py: PASS Memory - 02_defgetmem.py: PASS Memory - 03_mem_gi_errs.py: PASS NetworkPort - 01_netport.py: PASS NetworkPort - 02_np_gi_errors.py: PASS NetworkPort - 03_user_netport.py: FAIL Processor - 01_processor.py: PASS Processor - 02_definesys_get_procs.py: PASS Processor - 03_proc_gi_errs.py: PASS Profile - 01_enum.py: SKIP Profile - 02_profile_to_elec.py: SKIP Profile - 03_rprofile_gi_errs.py: SKIP RASD - 01_verify_rasd_fields.py: FAIL RASD - 02_enum.py: FAIL RASD - 03_rasd_errs.py: PASS ReferencedProfile - 01_verify_refprof.py: FAIL ReferencedProfile - 02_refprofile_errs.py: FAIL ResourceAllocationFromPool - 01_forward.py: PASS ResourceAllocationFromPool - 02_reverse.py: PASS ResourceAllocationFromPool - 03_forward_errs.py: FAIL ResourceAllocationFromPool - 04_reverse_errs.py: PASS ResourceAllocationFromPool - 05_RAPF_err.py: PASS ResourcePool - 01_enum.py: SKIP ResourcePool - 02_rp_gi_errors.py: SKIP ResourcePoolConfigurationCapabilities - 01_enum.py: PASS ResourcePoolConfigurationCapabilities - 02_rpcc_gi_errs.py: PASS ResourcePoolConfigurationService - 01_enum.py: PASS ResourcePoolConfigurationService - 02_rcps_gi_errors.py: PASS ResourcePoolConfigurationService - 03_CreateResourcePool.py: FAIL ResourcePoolConfigurationService - 04_CreateChildResourcePool.py: FAIL ResourcePoolConfigurationService - 05_AddResourcesToResourcePool.py: XFAIL Bug: 92173 ResourcePoolConfigurationService - 06_RemoveResourcesFromResourcePool.py: FAIL ResourcePoolConfigurationService - 07_DeleteResourcePool.py: FAIL SettingsDefine - 01_forward.py: PASS SettingsDefine - 02_reverse.py: PASS SettingsDefine - 03_sds_fwd_errs.py: PASS SettingsDefine - 04_sds_rev_errs.py: PASS SettingsDefineCapabilities - 01_forward.py: SKIP SettingsDefineCapabilities - 03_forward_errs.py: SKIP SettingsDefineCapabilities - 04_forward_vsmsdata.py: SKIP SettingsDefineCapabilities - 05_reverse_vsmcap.py: SKIP SystemDevice - 01_forward.py: PASS SystemDevice - 02_reverse.py: PASS SystemDevice - 03_fwderrs.py: PASS VSSD - 01_enum.py: PASS VSSD - 02_bootldr.py: SKIP VSSD - 03_vssd_gi_errs.py: SKIP VSSD - 04_vssd_to_rasd.py: FAIL VirtualSystemManagementCapabilities - 01_enum.py: PASS VirtualSystemManagementCapabilities - 02_vsmcap_gi_errs.py: PASS VirtualSystemManagementService - 01_definesystem_name.py: PASS VirtualSystemManagementService - 02_destroysystem.py: FAIL VirtualSystemManagementService - 03_definesystem_ess.py: PASS VirtualSystemManagementService - 04_definesystem_ers.py: PASS VirtualSystemManagementService - 05_destroysystem_neg.py: PASS VirtualSystemManagementService - 06_addresource.py: FAIL VirtualSystemManagementService - 07_addresource_neg.py: PASS VirtualSystemManagementService - 08_modifyresource.py: XFAIL Bug: 90853 VirtualSystemMigrationCapabilities - 01_enum.py: PASS VirtualSystemMigrationCapabilities - 02_vsmc_gi_errs.py: PASS VirtualSystemMigrationService - 01_migratable_host.py: SKIP VirtualSystemMigrationService - 02_host_migrate_type.py: SKIP VirtualSystemMigrationService - 05_migratable_host_errs.py: SKIP VirtualSystemMigrationSettingData - 01_enum.py: PASS VirtualSystemMigrationSettingData - 02_vsmsd_gi_errs.py: PASS VirtualSystemSettingDataComponent - 01_forward.py: SKIP VirtualSystemSettingDataComponent - 02_reverse.py: SKIP VirtualSystemSettingDataComponent - 03_vssdc_fwd_errs.py: SKIP VirtualSystemSettingDataComponent - 04_vssdc_rev_errs.py: SKIP VirtualSystemSnapshotService - 01_enum.py: PASS VirtualSystemSnapshotService - 02_vs_sservice_gi_errs.py: PASS VirtualSystemSnapshotServiceCapabilities - 01_enum.py: PASS VirtualSystemSnapshotServiceCapabilities - 02_vs_sservicecap_gi_errs.py: PASS -- - Zhengang
ZL> ComputerSystemIndication - 01_created_indication.py: FAIL ZL> Exception : Authentication (or request) Failed! ZL> Previous tests were always on sfcb. Anyone has a successful experience ZL> on pegasus for indication? Make sure you have the following in your cimconfig: repositoryIsDefaultInstanceProvider=true enableIndicationService=true -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Dan Smith wrote:
ZL> ComputerSystemIndication - 01_created_indication.py: FAIL ZL> Exception : Authentication (or request) Failed! ZL> Previous tests were always on sfcb. Anyone has a successful experience ZL> on pegasus for indication?
Make sure you have the following in your cimconfig:
repositoryIsDefaultInstanceProvider=true enableIndicationService=true Tried with the two properties set to true. Still the same error message.
------------------------------------------------------------------------
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
-- - Zhengang
ZL> Tried with the two properties set to true. Still the same error ZL> message. Can you try a manual test with the indication tester to see if it's actually working? The test passes for me on Pegasus, but it could be related to something like an incorrect determination of your hostname, or something like that. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Dan Smith wrote:
ZL> Tried with the two properties set to true. Still the same error ZL> message.
Can you try a manual test with the indication tester to see if it's actually working? The test passes for me on Pegasus, but it could be related to something like an incorrect determination of your hostname, or something like that.
I tried this last night, and I saw the same error. F9 uses Pegasus 2.7, while F8 used 2.6.1, which might be the cause. I looked at the cimconfig options for 2.7, and I didn't notice anything obvious. But I plan on looking into it more today. -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
Zhengang Li wrote:
Distro: Fedora 9 Beta Kernel: 2.6.25-0.121.rc5.git4.fc9 Libvirt: 0.4.1-7.fc9 CIMOM: 2.7.0-6.fc9 PyWBEM: 0.6-1 libcmpiutil: 0.3-1.fc9 libvirt-cim: 0.3-4.fc9 cimtest: changeset-76
=========FAIL============= AllocationCapabilities - 02_alloccap_gi_errs.py: FAIL "Requested Object could not be found." vs. "Instance not found." error string issue. The return code is correct. [Known Issue]
Dan has submitted a patch that sets the changeset number and revision number of the providers as attributes in the VSMS class. Could you add a function that gets these values, and then sets them as globals for the suite? This will allow the individual test cases to use the changeset/revision number as a way to check for different behavior depending on when a particular patch went in. Also, there was some discussion on the mailing list about modifying the negative test cases so that they only check the provider return codes. I think it'll be awhile before we can add implementation specific return codes to the providers. Since the CIM return codes aren't specific enough to indicate exactly what kind of error occurred, I'm inclined to continue checking the return messages in the test cases for now. Thoughts?
ComputerSystemIndication - 01_created_indication.py: FAIL Exception : Authentication (or request) Failed! Previous tests were always on sfcb. Anyone has a successful experience on pegasus for indication?
I had this on my to-do list today, but I didn't have a chance to look at it. -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
Kaitlin Rupert wrote:
AllocationCapabilities - 02_alloccap_gi_errs.py: FAIL "Requested Object could not be found." vs. "Instance not found." error string issue. The return code is correct. [Known Issue]
Dan has submitted a patch that sets the changeset number and revision number of the providers as attributes in the VSMS class.
Could you add a function that gets these values, and then sets them as globals for the suite? This will allow the individual test cases to use the changeset/revision number as a way to check for different behavior depending on when a particular patch went in. Ok, I'll add that today.
Also, there was some discussion on the mailing list about modifying the negative test cases so that they only check the provider return codes. I think it'll be awhile before we can add implementation specific return codes to the providers. Since the CIM return codes aren't specific enough to indicate exactly what kind of error occurred, I'm inclined to continue checking the return messages in the test cases for now.
Thoughts?
I agree with you on checking both the return codes and the messages. But I thought branching the test cases for different changeset of providers is a little risky. I am in the mood that we're going to maintain massive if-else branches on this if the provider message strings change too fast. An optimistic view would be that even though we need to maintain a little bit too many of branches at first. But as the providers get more stable, these frequent changes are less likely to happen. Ok, my third view is a little unrealistic. We can develop a fifth test case return code, named 'conditional pass', specifically for the rc matches, string doesn't match issue. :=) -- - Zhengang
Also, there was some discussion on the mailing list about modifying the negative test cases so that they only check the provider return codes. I think it'll be awhile before we can add implementation specific return codes to the providers. Since the CIM return codes aren't specific enough to indicate exactly what kind of error occurred, I'm inclined to continue checking the return messages in the test cases for now.
Thoughts? I agree with you on checking both the return codes and the messages. But I thought branching the test cases for different changeset of providers is a little risky. I am in the mood that we're going to maintain massive if-else branches on this if the provider message strings change too fast.
Completely agree - they've already been a headache to maintain as it is.
An optimistic view would be that even though we need to maintain a little bit too many of branches at first. But as the providers get more stable, these frequent changes are less likely to happen.
Ok, my third view is a little unrealistic. We can develop a fifth test case return code, named 'conditional pass', specifically for the rc matches, string doesn't match issue. :=)
While not a bad idea, maintaining yet another return code can be a pain. Especially if it doesn't get set back to pass/fail when need be. Heidi was working on updating these message, and is most of the way done. From your F9 release providers test run, it looks like 1 or possibly 2 tests cases that encounter this issue. I'm inclined to have these tests branch for now. If I see a trend that more error messages are changing, then add something like an additional return code. Either way, I'd say leave these test cases as a lower priority to fix for now. I'd rather focus on ensuring the more complex tests pass on KVM. =) -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
participants (3)
-
Dan Smith -
Kaitlin Rupert -
Zhengang Li