[Bug 1547528] [NEW] How to handle specific HW needs for dep8 tests in CI

[ChristianEhrhardt]

On Fri, Feb 19, 2016 at 6:35 PM, Martin Pitt <martin.pitt at ubuntu.com>
wrote:

> ChristianEhrhardt [2016-02-19 14:02 -0000]:
>
 [...]

> > But later infinity pointed out if we shouldn't bump our scalingstack
> > machine configs as all underlying HW would support that.  In our
> > case that would be the flavour autopkgtest.
>
> I'm not sure if such options can be specified in Openstack Nova
> flavors, but I'm in no way an expert there. I suggest that you open an
> RT and ask IS about that?
>

I'll discuss with IS if it would be possible to "raise" the flavours
definition, but even if possible it is not clear how to proceed.
Because if we "just raise the flavour in general" we loose a bit of the
generic baseline test.

For example we might miss some things that fail (and other than our last
test should fail) because of such missing feature.
That is why we look to some kind of d/t/* definition to select/restrict
such things.

Anyway I'll update here once I talked to IS about the possibility.


> Even if we get that, I still suggest to test /proc/mounts and skip the
> test -- after all, people want to run these tests in other envs than
> the Canonical data center.


We already did and uploaded - thanks for the suggestion on IRC.


> > In later discussions there were arguments that for specific software
> > should have some kind of exception process where e.g. some part of the
> > d/t/control should be able to specify those needs as Restriction/Class
> > /or-else.
>
> Class: would be possible, but this is a very specific requirement, and
> dpdk would probably remain the only user of it. So let's not
> over-design this :-) Also, we don't yet actually implement test
> classes. But first and foremost, we don't have testbeds that support
> SSE3, so the above Nova config discussion will have to be done either
> way.


Yeah I'd also dislike a very test specific "+sse3-Class".
If modified flavours turns out to be possible at all - we might want more
something like:
- flavour autopkgtest - being the generic baseline generally used
- flavour "modern-cpu-autopkgtest" that is the highest common denominator
of what the infrastructure provides

[...]


> You can already specify options to adt-virt-qemu, so this is already
> available. But QEMU options absolutely don't belong into d/t/control,
> so this isn't going to happen either.
>

Oh yes we already used that to adt-virt-qemu to verify and it worked
fine.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dpdk in Ubuntu.
https://bugs.launchpad.net/bugs/1547528

Title:
  How to handle specific HW needs for dep8 tests in CI

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/1547528/+subscriptions