<tt>libvirt-cim-bounces@redhat.com wrote on 2008-11-13 07:44:12: > > > >> > > It fails because of different error code and desc for F9 rpm > > > >> and F10. > > > >> > > With invalid_instid_keyvalue, it expected to return {'rc' : > > > >> > > pywbem.CIM_ERR_FAILED, 'desc' : 'Unable to determine resource > > type'} > > > >> > > for F9, > > > >> > > but we expected to return {'rc' : pywbem.CIM_ERR_NOT_FOUND, > > > >> 'desc' : > > > >> > > 'No such instance'} for F10. > > > >> > > > > > >> > > I have to add a revision branch here. Would you tell me how > > to get > > > >> > > the revision number? > > > >> > Yes this test need to be branched. > > > >> > You can use get_provider_version() to get he revision number. > > > >> > You can refer to 15_mod_system_settings.py tc for reference. > > > >> > > > >> Deepti - Thanks for your relpy. > > > >> When I try to get the changeset number for this patch, It seems > > > >> that the expect > > > >> error code number and desc are not changed yet, below is the part > > > >> code for > > > >> this case in Virt_SettingsDefineCapabilities.c with current src: > > > >> > > > >> ... > > > >> if (type == CIM_RES_TYPE_UNKNOWN) { > > > >> cu_statusf(_BROKER, &s, > > > >> CMPI_RC_ERR_FAILED, > > > >> "Unable to determine resource type"); > > > >> goto out; > > > >> } > > > >> ... > > > > Sorry I did not ask initially itself. > > > > Which CIMOM did use when comparing the return values. > > > > Do you use the same CIMOM on both F9 and F10 ? > > > If the problem is with different CIMOM's returning different error > > > information then we dont need to use get_provider_version(). > > > It would be good idea to verify what CIMOM is there on the machine and > > > check the error information accordingly instead of modifying and > > > verifying the common information in the error description for pegasus > > > and sfcb.This will be good in case where two error messages occurring > > > because of different reasons are partly same, and hence avoid false > > > positives. > > > > This tc return both different error code and descriptions for sfcb and > > pegasus. > > It seems that somebody says it isn't a good idea to check the cimom > > type in tc. > > I'm not sure if we can deal with this by other ways. > > Thanks! > > Daisy - did you resolve your problem? I tested with an F9 rpm using > Pegasus, and this test passed for me. > > </tt> <tt> This tc passes for Pegasus, but it fails for sfcb.</tt> <tt> It expects different error code and description for sfcb and Pegasus.</tt> <tt> </tt> <tt> If I change the expr_valuese from 1) to 2), it passes for sfcb.</tt> <tt> 1) </tt> <tt>expr_values = {</tt> <tt> "invalid_instid_keyvalue" : { 'rc' : pywbem.CIM_ERR_FAILED,</tt> <tt> 'desc' : 'Unable to determine\</tt> <tt> resource type' },</tt> <tt> }</tt> <tt> 2) </tt> <tt>expr_values = {</tt> <tt> "invalid_instid_keyvalue" : { 'rc' : pywbem.CIM_ERR_NOT_FOUNG,</tt> <tt> 'desc' : 'No such instance' },</tt> <tt> }</tt> <tt> Maybe we can verify what CIMOM is there on the machine and check the error information accordingly to fix this issue,</tt> <tt> but I remember that somebody says it isn't a good idea to check the cimom type in tc, any better idea?</tt> <tt> Thanks!</tt> <tt> > -- > Kaitlin Rupert > IBM Linux Technology Center > kaitlin@linux.vnet.ibm.com > > _______________________________________________ > Libvirt-cim mailing list > Libvirt-cim@redhat.com > https://www.redhat.com/mailman/listinfo/libvirt-cim </tt>