> Can some of the testing be shortened Well the test really does nothing other than run 'ssh' from container A to container B before sshuttle is run and again while it's running. So (other than timeouts) the test can't be shortened much. I think most of the time comes from timeouts and the lxd container management.
> or run in parallel? I wish...I tried, this was rejected: https://code.launchpad.net/~ddstreet/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/401036 If you can change vorlon's mind that would be great; the 'big' tests get 4 vcpus so things could (theoretically) be parallelized up to 4 tests at once. However, if the reduction of timeouts and any lxd image handling improvements are done, the test might not need more cores; and also if the main cause of the long test isn't being cpu-bound then parallelization may not help. > A quick look at the logs suggests that a lot of time is spent waiting on timeouts. Perhaps the timeouts could be configured to a shorter number in some cases? probably so, i uploaded a new version (to impish) that reduces the expected timeouts down to 20 seconds, and also the detection of when sshuttle had started seems to have not been working in all cases (since it seems the sshuttle output on success varies across releases). Hopefully this will speed it up some. You might be able to get the length down more by messing with lxd to see if you can use an approach other than snapshotting to put each test instance back into a 'fresh' state; maybe even just re-launching instead of restoring from snapshot. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1927757 Title: sshuttle autopkgtest is rather lengthy To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sshuttle/+bug/1927757/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
