2:23 a.m.
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
11:28 a.m.
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(a)us.ibm.com
8:54 p.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-cim
--
- Zhengang
8:42 a.m.
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(a)us.ibm.com
8:59 a.m.
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(a)linux.vnet.ibm.com
8:24 p.m.
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(a)linux.vnet.ibm.com
8:56 p.m.
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
5:40 p.m.
> 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(a)linux.vnet.ibm.com
6057
days inactive
6059
days old
7 comments
3 participants
participants (3)
-
Dan Smith -
Kaitlin Rupert -
Zhengang Li