[Libvirt-cim] [PATCH] [TEST] Updating the 01_forward.py tc in SettingsDefineCapabilities

Deepti B Kalakeri deeptik at linux.vnet.ibm.com
Wed Apr 23 08:12:08 UTC 2008



Guo Lian Yun wrote:
>
> libvirt-cim-bounces at redhat.com wrote on 2008-04-22 22:53:33:
>
> > > - at do_main(sup_types)
> > > +def verify_rasd_fields(loop, assoc_info, cllist, rtype, rangelist):
> > > +    status = PASS
> > > +    for inst in assoc_info:
> > > +        if inst.classname != cllist[loop]:
> > > +            print_error("Classname", inst.classname, cllist[loop])
> > > +            status = FAIL
> > > +        if inst['ResourceType'] != rtype[cllist[loop]]:
> > > +            print_error("ResourceType", inst['ResourceType'],
> > > +                                              rtype[cllist[loop]])
> > > +            status = FAIL
> > > +        ppolicy = inst['PropertyPolicy']
> > > +        if ppolicy != 0 and ppolicy != 1:
> > > +            print_error("PropertyPolicy", inst['PropertyPolicy'], 
> ppolicy)
> > > +            status = FAIL
> > > +        vrole  = inst['ValueRole']
> > > +        if vrole < 0 or vrole > 4:
> > > +            print_error("ValueRole", inst['ValueRole'], vrole)
> > > +            status = FAIL
> > > +        insid  = inst['InstanceID']
> > > +        vrange = rangelist[insid]
> > > +        if vrange != inst['ValueRange']:
> > > +            print_error("ValueRange", inst['ValueRange'], vrange)
> > > +            status = FAIL
> > > +        if status != PASS:
> > > +            break
> > > +    return status
> > > +
> > > +
> >
> > Nice job on turning this into a function. I think this makes things 
> more
> > readable. I know this is just a reshuffling of code, but can you modify
> > it so that we return an error instead of just setting the status to
> > FAIL?  That way, we bail out immediately.
> >
> > Also, this test fails for me on F9 with KVM using current sources. 
>  This
> > is because the current providers use diskpools (which you need a 
> version
> > of libvirt 0.4.0 or newer, I believe).
> >
>
I use the libvirt-cim rpm on my F9 machine for testing.
Do you want me to use the new provider source for testing on F9 machine 
also ?
>
> > Daisy was going to look into working out a disk pool fix, so you might
> > want to check with her to see if she's still planning on this.
> >
>
> I'm looking into the EAFP 01_forward.py and EAFP 02_reverse.py failing
> issue, they fail for me on F8 with Xen on my own machine, but pass
> on the other machine.
>
> On the diskpool, the following is the list of what we have to do:
>
> 1) Move diskpool config functions to a library and updated related
>    test case.
>
> 2) Create diskpool file function in the same library as above.
>    I'm not sure if I catch up the essential difference between
>    diskpool and diskpool file? Why libvirt-0.4.0 or newer ignore
>    the diskpool stuff and use a file?
>
> 3) Add function to check the version of libvirt. If libvirt >= 0.4.0,
>    we'll need to call creating diskpool file function.
>    Any better way for geting the libvirt version except parsing
>    the output of "rpm -qa libvirt"?
>
> At now, we put the diskpool.conf under /tmp, Dan and Katillin have
> discussed the best location for it, so what's the result?
>
> Thoughts?
>
>
> > --
> > 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
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Libvirt-cim mailing list
> Libvirt-cim at redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-cim




More information about the Libvirt-cim mailing list