Hi,
thanks for your info. I'm working on repair of this bug right now.
I think that I have already found some solution, but I must prove it.
It should take some time. I hope till this Sunday.
Yes, there is problem in might_pass in checking internal filters.
I'll check yours solution too. Thanks a lot. And I'll try to push to git the
better one.
regards,
Jiří Župka
----- Original Message -----
> On 02/19/2013 10:02 PM, Eduardo Habkost wrote:
> > On Tue, Feb 19, 2013 at 06:05:01PM +0800, Yiqiao Pu wrote:
> >> On 02/15/2013 03:20 AM, Eduardo Habkost wrote:
> >>> On Thu, Feb 14, 2013 at 04:53:01PM -0200, Eduardo Habkost wrote:
> >>>> Hi,
> >>>>
> >>>> I am using the config file pasted at the end of this message. It
> >>>> is
> >>>> supposed to generate two test dictionaries for some test cases
> >>>> (the
> >>>> custom.* variants), one with KVM enabled ("kvm"), and one with
> >>>> KVM
> >>>> disabled ("nokvm"). But the result is:
> >>>>
> >>>> $ virttest/cartesian_config.py /tmp/cpuid.cfg
> >>>> dict 1: cpuid.default_vendor.kvm.cpu.unset.unknown_qemu
> >>>> dict 2:
> >>>> cpuid.custom.vendor.normal.kvm.cpu.unset.unknown_qemu
> >>>> $
> >>>>
> >>>> It looks like a bug to me. Or maybe I am missing some small
> >>>> detail?
> >>> Managed to reduce the test case even further:
> >>>
> >>> ======================
> >>> variants:
> >>> - unknown_qemu:
> >>> - rhel64:
> >>> only unknown_qemu
> >>> variants:
> >>> - kvm:
> >>> - nokvm:
> >>> variants:
> >>> - testA:
> >>> nokvm:
> >>> no unknown_qemu
> >>> - testB:
> >>> =========================
> >>>
> >>> $ virttest/cartesian_config.py /tmp/cpuid.cfg
> >>> dict 1: testA.kvm.unknown_qemu
> >>> dict 2: testB.kvm.unknown_qemu
> >>> $
> >>>
> >>> testB.nokvm should have been skipped, but not testB.nokvm.
> >>>
> >>> Proof:
> >>>
> >>> $ virttest/cartesian_config.py /tmp/cpuid.cfg 'no testA'
> >>> dict 1: testB.kvm.unknown_qemu
> >>> dict 2: testB.nokvm.unknown_qemu
> >>> $
> >>>
> >>>
> >> Have a little test with your cfg file. And seems there is
> >> something
> >> wrong in the function might_pass() in get_dicts()
> >> It will return False when the content is empty. So maybe we need
> >> add
> >> a judgement for content in might_pass. Just add some line the end
> >> of
> >> that function like this, and I get the result we expect:
> >>
> >> if content:
> >> return False
> >> else:
> >> return True
> > What is the meaning of "content", exactly, and why should the
> > function
> > return False if content is non-empty, and return True if it is
> > empty?
> >
>
> Read the code again and seems the "content" is the current Condition
> object for the node. So if the "content" is empty, it means for this
> node we don't have any Condition object like filter and so on. So we
> should not failed this node in might_pass().
>
> _______________________________________________
> Virt-test-devel mailing list
> [email protected]
> https://www.redhat.com/mailman/listinfo/virt-test-devel
>
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
