| 2018-10-04 00:46:56 |
Dimitri John Ledkov |
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
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. |
$ 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. |
|
| 2018-10-04 00:53:58 |
Dimitri John Ledkov |
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
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. |
$ 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. |
|
