[Bug 1795999] [NEW] python3.6 test_ssl fails reliably on systems under load

[Dimitri John Ledkov]

Public bug reported:

$ 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.

** Affects: auto-package-testing
     Importance: Undecided
         Status: New

** Affects: python3.6 (Ubuntu)
     Importance: Undecided
         Status: New

** Also affects: auto-package-testing
   Importance: Undecided
       Status: New

** Description changed:

  $ 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
  
  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.

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

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

Status in Auto Package Testing:
  New
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