canonical-ubuntu-qa team mailing list archive

[Skia <1795999@xxxxxxxxxxxxxxxxxx>]

That was too long ago now, everything has changed since then.

** Changed in: auto-package-testing
       Status: Incomplete => Won't Fix

-- 
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to Auto Package Testing.
https://bugs.launchpad.net/bugs/1795999

Title:
  python3.6 test_ssl fails reliably on systems under load

Status in Auto Package Testing:
  Won't Fix
Status in python3.6 package in Ubuntu:
  New

Bug description:
  $ autopkgtest-buildvm-ubuntu-cloud --arch i386

  put system under load; e.g. pull-lp-source boost1.67; cd boost1.67;
  DEB_BUILD_OPTIONS=parallel=12 ./debian/rules build should do it, on an
  4core/8hypercore system

  $ autopkgtest -s --shell --apt-pocket=proposed --apt-upgrade python3.6
  --test-name testsuite -- qemu -c 1 -q qemu-system-i386 ./autopkgtest-
  cosmic-i386.img

  test_ssl fails

  To rerun test_ssl alone, one can do:
  $ python3.6 -W default -bb -E -R -m test -j 1 -w -uall,-network,-urlfetch,-gui test_ssl --verbose

  in a racy manner, for many test cases, due to ConnectionRefused from
  the TestEchoServer

  One way to solve this is to reduce the load, cause without load
  TestEchoServer keeps up just fine.

  Symptoms are s.connect failing with ConnectionRefusedError, or for
  example s.getpeercreds failing with Transport not connected.

  I'm not sure it's worth any time fixing this test-server
  implementation, as clearly it is testing the ssl server/client bits,
  that work correctly on a normal, not-under-stress systems. And thus
  the ssl bits are correctly validated.

  I will try to create a reproducer which does not involve VMs and
  stressing host.

  meanwhile it would be nice to run python tests on slightly bigger
  machines, e.g. mark it as big_packages.

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