[Commotion-dev] Python-based testing framework across Ubuntu/Debian and Android (and maybe OSX)?

[Ben West]

Responses in-line, in green if your email client can do that sort of thing
...

On Tue, Apr 2, 2013 at 9:44 AM, seamus tuohy <s2e at opentechinstitute.org>wrote:

>  On 04/02/2013 10:31 AM, Ben West wrote:
>
>  Hi Seamus and Dan,
>
>  Replying about having Python on (and off) OpenWRT:
>
> The cross-platform nature seems like it would be very helpful to maintain
> a single collection of tests vectors to apply as Commotion finds its way
> onto more platforms (Windows, OSX).  But, the obvious tradeoff here is the
> size of the Python interpreter.
>
>
> Agreed!
>
>
>  Also, the test scripts that query a node's OLSR instance via jsoninfo
> could also run *on the client*, rather than directly on the node.  The
> node would just need to open up the jsoninfo port 9090 on its firewall
> behind the public AP interface (or have the client use its private AP).  I
> can tweak the Python scripts (tho very little needed) to accommodate this
> option.
>
>
> I think that is a great idea for the openWRT instances. Though, as we get
> the other platforms up and running it will be less and less needed, since
> we will be running more powerful devices as nodes.
>
>
OLSRd will only report details like link quality and routing topology.  For
lower-level hardware information about the wireless interface, e.g. dBm of
remote APs, TX retries, I would highly recommend Henning's fabulous LDEP
implementation that is now in the CONFINE repo.  That is, the python test
script on the client's machine could query data both from the node's OLSRd
instance via jsoninfo, and also from its LDEP daemon.  And Henning would be
thrilled. :)

LDEP implementation targeted at nl80211 for OpenWRT:
http://wiki.confine-project.eu/soft:dlep
http://wiki.confine-project.eu/soft:confine-dist
https://github.com/confine-project/confine-dist/tree/master/packages/confine(as
packaged into Confine)
http://olsr.org/git/?p=dlep_app.git;a=tree (the current repo?)


>
>  Besides that, I think I may be able to tweak the Python Makefile
> provided with OpenWRT, so that the compiled package is much smaller than
> its current 1.5MByte footprint.  The Python v2.6 implementation bundled
> into Py4A (which runs all these tests fine) is *only 150kB*, by
> comparison.  Still, admitted that installing another language on what is
> already disk- and RAM-bound devices is less than ideal.
>
>
> I don't know what the consensus is, but as much as I would love to start
> to play with python on the OpenWRT nodes, I think we will be able to use
> the existing testing code you built, along with some client based tweaks to
> accurately test a OpenWRT based mesh.
>
>
I've so far trimmed the OpenWRT python-mini package down to ~1.2MB, now
including unittest.  1.0MByte may be doable with more strenuous weight
loss.  This package could still be handy to have on hand for reference
(i.e. as optional add-on module for Commotion).  I will soon share a repo
with the modified Makefile


>
>
>  Finally, sorry for using the term 'bytecode.'  That's not really what we
> need; compiled Python bytecode is neither smaller than source nor
> stand-alone executable.  What I meant is maybe compile the Python testsuite
> into a single standalone executable using a tool like these:
> http://cx-freeze.sourceforge.net/
> http://www.pyinstaller.org/
>
> Likewise, if running the Python test suite directly on nodes becomes a
necessity, this option to compile those scripts into stand-alone
executables is still there.  Assume the OpenWRT Makefile-foo required for
this is not outrageous.


-- 
Ben West
http://gowasabi.net
ben at gowasabi.net
314-246-9434
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20130402/33170cb9/attachment.html>