libvirt-cim-bounces(a)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.
This tc passes for Pegasus, but it fails for sfcb.
It expects different error code and description for sfcb and Pegasus.
If I change the expr_valuese from 1) to 2), it passes for sfcb.
1)
expr_values = {
"invalid_instid_keyvalue" : { 'rc' : pywbem.CIM_ERR_FAILED,
'desc' : 'Unable to determine\
resource type' },
}
2)
expr_values = {
"invalid_instid_keyvalue" : { 'rc' : pywbem.CIM_ERR_NOT_FOUNG,
'desc' : 'No such instance' },
}
Maybe we can verify what CIMOM is there on the machine and check the
error information accordingly to fix this issue,
but I remember that somebody says it isn't a good idea to check the cimom
type in tc, any better idea?
Thanks!
--
Kaitlin Rupert
IBM Linux Technology Center
kaitlin(a)linux.vnet.ibm.com
_______________________________________________
Libvirt-cim mailing list
Libvirt-cim(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-cim