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

[Lukáš Doktor]

Dne 11.7.2016 v 05:05 xutian napsal(a):
>
>
> On 07/11/2016 07:49 AM, Cleber Rosa wrote:
>>
>> On 07/08/2016 06:18 AM, Lukáš Doktor wrote:
>>> Dne 30.6.2016 v 21:21 Eduardo Habkost napsal(a):
>>>> While trying to run the cpuid test cases using avocado-vt, I
>>>> found out that the machine_rhel variants are being automatically
>>>> filtered out. Then I found out that the most recent version of
>>>> qemu_cpu.cfg depends on a "Host_RHEL" variant being defined.
>>>>
>>>> I don't know how this host-version check system works. Does
>>>> anybody know how to make the Host_RHEL variant be defined and
>>>> available when running the test cases under avocado-vt?
>>>>
>>>> Or is this Host_* magic not supported by avocado-vt yet and we
>>>> can't run any of the variants containing "only Host_RHEL" under
>>>> avocado-vt?
>>>>
>>> Hello Eduardo,
>>>
>>> I haven't played with that part for a while, but Host_RHEL used to be
>>> set by the internal runner used by QA and I don't think it was added to
>>> avocado-vt, therefor the filters should not be pushed upstream (or the
>>> support for it should have been added as well).
>>>
>>> CC: Xu and Feng, do you guys know more about this?
>>>
>>> Regards,
>>> Lukáš
>>>
>> Eduardo and Lukáš,
>>
>> As you're surely noticed, I was even more confused than you guys.  The
>> extra confusion was caused by the fact that, when I started to review:
>>
>>   https://github.com/autotest/tp-qemu/pull/686
>>
>> I was still unaware of this thread.  Looks like a MUA problem, but
>> that's now irrelevant.
>>
>> The important thing here is that, under no circumstance, we can have
>> upstream code that depends on tools, configuration files, or know-how
>> that's not upstream.  I'm not judging the "Host_*" variant creation
>> mechanism at this point, but simply stating that *any* upstream user
>> should be able to run tests.  At the most, users should be able to read
>> documentation and setup their systems accordingly, but the information
>> should be available.
>>
>> Feng, Xu,
>>
>> We really need you help.  First to identify what kind of tool is
>> generating the "Host_" variants config files.  Second, to port that to
>> upstream Avocado-VT.
> "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,
> Xu
>
>>
>> Thanks!
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/avocado-devel/attachments/20160711/32fdc51e/attachment.sig>