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

[Martin Pitt]

There is nothing to fix in the autopgtest package, so moving to the more
generic project (which also encompasses the infrastructure to run
tests).

** Package changed: autopkgtest (Ubuntu) => auto-package-testing

** Changed in: auto-package-testing
       Status: New => Incomplete

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

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

Status in Auto Package Testing:
  Incomplete
Status in dpdk package in Ubuntu:
  New

Bug description:
  It all started out as a typical case of "something happened".
  Looking at the CI history of openvswitch-dpdk at http://autopkgtest.ubuntu.com/packages/o/openvswitch-dpdk/xenial/amd64/.
  We weren't sure if the test machines or any other part of the execution changed.
  But due to that we found that in our case sse3 can't be guaranteed in the test environment - so we agreed on ubuntu-devel that we should detect and skip the test then to avoid false positives.

  Overall in the discusion pitti pointed out there is no current way to specify in d/t/control any kind of Restriction or Class that would allow us to get sse3 (or any similar explicit HW feature) guaranteed in an adt-run environment.
  He also pointed out that that was too specific for the test to make a general change.
  And that is right as we want some kind of general baseline that all things work on.

  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.
  While that is right and would fix "our" issue it would also lift the "general baseline" that we have and I can't decide if that is right.

  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.

  I don't want to suggest how this would be implemented best:
  - bump flavours
  - implement new type of restriction in d/t/control
  - implement even qemu-opt in d/t/control
  - ...
  but we agreed to at least open the bug for an open discussion around it.


  Some more background how this started at
  http://irclogs.ubuntu.com/2016/02/19/%23ubuntu-devel.html#t07:08
  http://irclogs.ubuntu.com/2016/02/19/%23ubuntu-devel.html#t11:04

  Plus a hangout discussion later between jamespage rbasak and me.
  Eventually it is a thing that needs proper discussion and evaluation how we want to proceed, so it is worth a bug to do so.

  Subscribing all participants of the discussion so far: pitti,
  infinity, rbasask, jamespage

To manage notifications about this bug go to:
https://bugs.launchpad.net/auto-package-testing/+bug/1547528/+subscriptions