<tt>libvirt-cim-bounces@redhat.com wrote on 2008-11-11 18:09:52: > > > Deepti B Kalakeri wrote: > > > > > > Guo Lian Yun wrote: > >> > >> libvirt-cim-bounces@redhat.com wrote on 2008-11-11 16:38:35: > >> > >> > > >> > > >> > Guo Lian Yun wrote: > >> > > > >> > > libvirt-cim-bounces@redhat.com wrote on 2008-11-10 14:35:33: > >> > > > >> > > > This will fail for F9 rpm. > >> > > > >> > > 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.</tt> <tt> This tc return both different error code and descriptions for sfcb and pegasus.</tt> <tt> It seems that somebody says it isn't a good idea to check the cimom type in tc.</tt> <tt> I'm not sure if we can deal with this by other ways.</tt> <tt> Thanks!</tt> <tt> </tt> <tt> > Any thoughts?? > > Thanks and Regards, > Deepti. > >> > >> > Thanks and Regards, > >> > Deepti. > >> > > Thanks! > >> > > > >> > > > > >> > > > Regards, > >> > > > Deepti. > >> > > > > >> > > > yunguol@cn.ibm.com wrote: > >> > > > > # HG changeset patch > >> > > > > # User Guolian Yun <yunguol@cn.ibm.com> > >> > > > > # Date 1226297098 28800 > >> > > > > # Node ID c85ded9735f60db2fc49475906e3611616a4a315 > >> > > > > # Parent 6591949e8afdddce6aa72022e33f0ce063ec60a1 > >> > > > > [TEST] Fix SettingsDefineCapabilities/03_forward_errs.py > >> > > > > > >> > > > > Signed-off-by: Guolian Yun <yunguol@cn.ibm.com> > >> > > > > > >> > > > > diff -r 6591949e8afd -r c85ded9735f6 suites/libvirt- > >> > > > cim/cimtest/SettingsDefineCapabilities/03_forward_errs.py > >> > > > > --- a/suites/libvirt- > >> > > > cim/cimtest/SettingsDefineCapabilities/03_forward_errs.py Wed > >> Nov > >> > > > 05 22:03:48 2008 -0800 > >> > > > > +++ b/suites/libvirt- > >> > > > cim/cimtest/SettingsDefineCapabilities/03_forward_errs.py Sun > >> Nov > >> > > > 09 22:04:58 2008 -0800 > >> > > > > @@ -40,9 +40,8 @@ > >> > > > > expr_values = { > >> > > > > "invalid_instid_keyname" : { 'rc' : > >> pywbem.CIM_ERR_FAILED, > >> > > > > 'desc' : 'Missing > >> InstanceID'}, > >> > > > > - "invalid_instid_keyvalue" : { 'rc' : pywbem.CIM_ERR_FAILED, > >> > > > > - 'desc' : 'Unable to determine\ > >> > > > > - resource type' }, > >> > > > > + "invalid_instid_keyvalue" : { 'rc' : > >> pywbem.CIM_ERR_NOT_FOUND, > >> > > > > + 'desc' : 'No such instance'}, > >> > > > > } > >> > > > > > >> > > > > def err_invalid_instid_keyname(virt, conn, field): > >> > > > > > >> > > > > _______________________________________________ > >> > > > > Libvirt-cim mailing list > >> > > > > Libvirt-cim@redhat.com > >> > > > > https://www.redhat.com/mailman/listinfo/libvirt-cim > >> > > > > > > > > >> > > > _______________________________________________ > >> > > > Libvirt-cim mailing list > >> > > > Libvirt-cim@redhat.com > >> > > > https://www.redhat.com/mailman/listinfo/libvirt-cim > >> > > > >> ------------------------------------------------------------------------ > >> > > > >> > > _______________________________________________ > >> > > Libvirt-cim mailing list > >> > > Libvirt-cim@redhat.com > >> > > https://www.redhat.com/mailman/listinfo/libvirt-cim > >> > > >> > _______________________________________________ > >> > Libvirt-cim mailing list > >> > Libvirt-cim@redhat.com > >> > https://www.redhat.com/mailman/listinfo/libvirt-cim > >> ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Libvirt-cim mailing list > >> Libvirt-cim@redhat.com > >> https://www.redhat.com/mailman/listinfo/libvirt-cim > > _______________________________________________ > Libvirt-cim mailing list > Libvirt-cim@redhat.com > https://www.redhat.com/mailman/listinfo/libvirt-cim </tt>