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

Guo Lian Yun yunguol at cn.ibm.com
Wed Apr 23 07:13:51 UTC 2008


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).
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-cim/attachments/20080423/6c4ce582/attachment.htm>


More information about the Libvirt-cim mailing list