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.
>
>
  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@linux.vnet.ibm.com
>
> _______________________________________________
> Libvirt-cim mailing list
> Libvirt-cim@redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-cim