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
_______________________________________________
Avocado-devel mailing list
Avocado-devel@redhat.com
https://www.redhat.com/mailman/listinfo/avocado-devel
