sshuttle autopkgtest is rather lengthy
Bug #1927757 reported by
Dan Bungert
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
sshuttle (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Focal |
Fix Committed
|
Undecided
|
Unassigned | ||
Groovy |
Won't Fix
|
Undecided
|
Unassigned | ||
Hirsute |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
Recent test runs of sshuttle autopkgtest are approaching 5 hours.
Here's time stats for 2 example runs on amd64 impish.
1.0.5-1ubuntu1 sshuttle/
1.0.5-1ubuntu1 sshuttle/
This can be seen as well in local autopkgtest testing.
Can some of the testing be shortened or run in parallel? 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?
tags: | added: block-focal-proposed block-groovy-proposed block-hirsute-proposed |
tags: |
added: block-proposed-focal block-proposed-groovy block-proposed-hirsute removed: block-focal-proposed block-groovy-proposed block-hirsute-proposed |
To post a comment you must log in.
> 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: /code.launchpad .net/~ddstreet/ autopkgtest- cloud/+ git/autopkgtest -cloud/ +merge/ 401036
https:/
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.