[Libvirt-cim] [PATCH] [TEST] Fix SettingsDefineCapabilities/03_forward_errs.py

[Guo Lian Yun]

libvirt-cim-bounces at 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 at linux.vnet.ibm.com
> 
> _______________________________________________
> Libvirt-cim mailing list
> Libvirt-cim at redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-cim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-cim/attachments/20081113/0c45924e/attachment.htm>