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

Paul Gardner-Stephen paul at servalproject.org
Tue Apr 2 19:34:02 UTC 2013


Hi All,

If it turns out that python is Just Too Big to fit on an OpenWRT
router, and shell-script ends up being the most feasible, we have a
shell-based test framework that we use to drive testing on the Serval
daemon code that might be of use.  Look in tests/ in the serval-dna
repo for the scripts we have created and the infrastructure behind
them.  Let me know if you want more info.

Paul.

On Wed, Apr 3, 2013 at 6:34 AM, Ben West <ben at gowasabi.net> wrote:
> 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
>
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> https://lists.chambana.net/mailman/listinfo/commotion-dev
>


More information about the Commotion-dev mailing list