On 07/11/2016 04:01 AM, Lukáš Doktor wrote: > 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 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. Thanks! - Cleber. >> Thanks, >> Xu >> >>> >>> Thanks! >>> >> > -- Cleber Rosa [ Sr Software Engineer - Virtualization Team - Red Hat ] [ Avocado Test Framework - avocado-framework.github.io ]
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Avocado-devel mailing list Avocado-devel@redhat.com https://www.redhat.com/mailman/listinfo/avocado-devel
