[Avocado-devel] avocado-vt: How to use Host_* variants?

[xutian]

On 07/13/2016 01:30 AM, Eduardo Habkost wrote:
> On Mon, Jul 11, 2016 at 06:40:17AM -0300, Cleber Rosa wrote:
>> On 07/11/2016 04:01 AM, Lukáš Doktor wrote:
>>> Dne 11.7.2016 v 05:05 xutian napsal(a):
>>>> "Host_" variants generate by internal tool "staf-kvm", the configuration
>>>> used to load RHEL host special configuration. Internal guys keep such
>>>> kind of configuration because qemu-kvm-rhev and qemu-kvm has different
>>>> feature list or /worse//yet, same feature in /qemu-kvm for RHEL6 and
>>>> qemu-kvm for RHEL7 has different behave (eg. drive mirror).And it's a
>>>> internal qemu-kvm issue not related upstream user, so we keep it in
>>>> internal repo.
>>>>
>>> Hello Xu,
>>>
>>> yep, that's what I thought. Btw isn't there a simpler way to distinguish
>>> between features? Most obvious would be `qemu-kvm -version` executed
>>> when `QContainer` is initialized. Then you can ask whether the qemu is
>>> `el6`, `el7`, `fc23` or sha from git.
>>>
>>> Alternatively we can add OS detection to avocado-vt, that should not be
>>> that hard ;-)
>>>
>>> Regards,
>>> Lukáš
>>>
>>>> Hi Cleber,
>>>>
>>>> that the story of "Host_" variants. if upstream guys don't like it, any
>>>> suggestion for resolve it.
>>>>
>> Thanks for the info Xu.  As I've said before, the issue here is not
>> about the mechanism itself, but the fact there's no way for an upstream
>> user to use it.
>>
>> IMHO we should start simply by porting what's done by "staff-kvm" into
>> either a contrib script, or "vt-boostrap" action.  Even sample
>> configuration files could do at this point.
>>
>> Then, at a later point, as Lukáš suggested, we can revisit how it's done.
> For the case of qemu_cpu.cfg, we can fix it by making it not
> depend on Host_* variants anymore (like it was before commit
> 78e66e64c9b7d2874c9f89327b2dbca9a8ff3b78). We can probably add a
> few rules to exclude some variants if Host_* is defined, but if
> Host_* is not defined we should try to test all machine-types.
If this test can works all machine-types, it's ok to remove filter 
only/no "Host_*". For internal
testing, we can keep this filter in internal configuration repo, so that 
we can ensure this test
works stable in internal qemu-kvm/qemu-kvm-rhev.

> Now, about the review process: what could we have done
> differently, to avoid commit 78e66e64 from being included in the
> first place?
>
> Maybe I should get more involved in reviewing the changes to the
> CPUID test code, but I don't know how to make sure I get notified
> when there are pending pull requests on cpuid.py and
> qemu_cpu.cfg.
Hi Eduardo,

If you like I will ping your if pull request submitted for CPUID test, 
and these kind of PR(s) will open a week to wait for your reviewing.

And if you are interested in other tests, please let me know, I will 
give a notification too.

Thanks,
Xu

>