Neil Williams codehelp@debian.org writes:
(sure we could find better names than lava-collect and lava-serve)
lava-nc-listen - offers files on a known port, opens the port lava-nc-connect - makes connections to each node using the port.
lava-sync processing-done
lava-sync connection-ready lava-nc-connect RESULTS-PATH DEST DEST DEST
# calculate ...
# run ... lava-sync processing-done
lava-nc-listen RESULTS-PATH lava-sync connection-ready
Each call to lava-nc-listen would have to put the call to nc into the background on each node and blindly trust nc to open the port on each node and close when it is done. The only indication that anything happened would then be when the connecting end completes the cycle of connecting to each node.
If tests want error checking, checksums, progress indication, resume support, incremental downloads or any other "typical" support, netcat isn't going to be suitable.
I've mostly had good results with netcat, but that's on highbank where the network does tend to work well, mileage on other devices would vary I bet.
I'm not sure we get much from the helpers that wouldn't be a lot easier to debug by using calls to tar and nc directly. It seems very flaky to me.
I think it's more about the test code being able to express its intent clearly.
SSH or HTTPServer&wget are a lot more work to setup in a test but much more usable. Therefore, I'd be much happier with test writers doing their own connection setup using more reliable tools, rather than possibly giving a false sense of security just because there is a helper available.
After all, HTTPServer&wget is exactly how LAVA sends data between the dispatcher and the board during deployment. It means installing python (or some other http daemon) on each node and wget on the receiver.
busybox implements both a simple httpd and wget :-)
Cheers, mwh