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

[Eduardo Habkost]

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.

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.

-- 
Eduardo