Public bug reported: 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 ** Affects: dpdk (Ubuntu) Importance: Undecided Status: New ** Summary changed: - way to define an exception from the generic baseline for dep8 tests e.g. specific processor features + How to handle specific HW needs for dep8 tests in CI -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to 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 -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
