[Bug 1285026] [NEW] FFE: New isolation restrictions, using shared dir

[Martin Pitt]

Public bug reported:

Tomorrow, when the current version goes into testing, I'll upload
autopkgtest 2.9 into Sid and would like to get that into trusty. The
full changelog can be seen at
http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob;f=debian/changelog
which includes some bug fixes. The two new features are:

  * Add test restrictions "isolation-container" and "isolation-machine", and
    corresponding testbed capabilities. Tests can use that to declare that
    they want to start services or open ports (i. e. a simple chroot/schroot
    is insufficient) or access hardware, reboot,  and interact the kernel
    (where even a container is insufficient), and will be skipped instead of
    failing when they run in a virtualization server which does not provide
    enough isolation.

This is technically a rather simple change and has tests. It will allow
us to mark tests like systemd, udisks2, network-manager, etc. as "does
not work in a container", so that they stop appearing as failures on
https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest%20armhf/ and
https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest%20ppc64el/ .

 * Rework the communication between adt-run and the virtualization
server to use a shared directory where supported, instead of cramming
all file copying into tar/cat through pipes.

This will avoid lots of file copying and make the whole thing faster,
but more importantly it provides live output of the test stdout/err
while they are running, not just a big stdout/err dump after the test
finished. It's a fairly intrusive change, but autopkgtest has a fairly
good test coverage now. Moreover, this change has already been active on
our 9 armhf and 4 ppc64el test boxes since Monday, as we use autopkgtest
from git there.

Should this change cause any trouble, it's a trivial change to the
corresponding virtualization server to disable it again (just drop the
shared-downtmp capability).

** Affects: autopkgtest (Ubuntu)
     Importance: Wishlist
         Status: New

** Changed in: autopkgtest (Ubuntu)
   Importance: Undecided => Wishlist

-- 
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/1285026

Title:
  FFE: New isolation restrictions, using shared dir

Status in “autopkgtest” package in Ubuntu:
  New

Bug description:
  Tomorrow, when the current version goes into testing, I'll upload
  autopkgtest 2.9 into Sid and would like to get that into trusty. The
  full changelog can be seen at
  http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob;f=debian/changelog
  which includes some bug fixes. The two new features are:

    * Add test restrictions "isolation-container" and "isolation-machine", and
      corresponding testbed capabilities. Tests can use that to declare that
      they want to start services or open ports (i. e. a simple chroot/schroot
      is insufficient) or access hardware, reboot,  and interact the kernel
      (where even a container is insufficient), and will be skipped instead of
      failing when they run in a virtualization server which does not provide
      enough isolation.

  This is technically a rather simple change and has tests. It will
  allow us to mark tests like systemd, udisks2, network-manager, etc. as
  "does not work in a container", so that they stop appearing as
  failures on
  https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest%20armhf/
  and
  https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest%20ppc64el/
  .

   * Rework the communication between adt-run and the virtualization
  server to use a shared directory where supported, instead of cramming
  all file copying into tar/cat through pipes.

  This will avoid lots of file copying and make the whole thing faster,
  but more importantly it provides live output of the test stdout/err
  while they are running, not just a big stdout/err dump after the test
  finished. It's a fairly intrusive change, but autopkgtest has a fairly
  good test coverage now. Moreover, this change has already been active
  on our 9 armhf and 4 ppc64el test boxes since Monday, as we use
  autopkgtest from git there.

  Should this change cause any trouble, it's a trivial change to the
  corresponding virtualization server to disable it again (just drop the
  shared-downtmp capability).

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