<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hey,<br>
      <br>
      On 04/02/2013 04:20 AM, Ben West wrote:<br>
    </div>
    <blockquote
cite="mid:CADSh-SMDToMuum4XyJ=jDwk0LxD5OW7fdWwFw2v3EEzVoGiLxQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>Hi All,<br>
              <br>
              I've created a repo of a few basic tests implemented as
              unittests in Python 2.6+.  This repo contains just the
              Python scripts themselves, so that it may be included
              later as a submodule into other repos containing
              platform-specific packaging stuff.<br>
              <a moz-do-not-send="true"
                href="https://github.com/westbywest/commotion-tests-core">https://github.com/westbywest/commotion-tests-core</a><br>
            </div>
            <br>
            Due please note I expect this repo to change, and even its
            location to maybe switch to OTI's github account at some
            point soon.<br>
            <br>
          </div>
          To serve as hopefully demonstrative examples of the test
          coverage possible, the scripts I just checked in test for the
          following:<br>
        </div>
        <div>
          <ul>
            <li>ping localhost</li>
            <li>ping gateway IP (either default gateway or the one
              assigned by OLSRd smartgateway)</li>
            <li>ping Google DNS (aka do we have Internet?)</li>
            <li>presence of an active olsrd process</li>
            <li>olsrd responds to jsoninfo requests</li>
            <li>link quality of the next hop is above a specified
              threshold</li>
          </ul>
        </div>
        <div>
          These scripts should run under the following Python versions /
          platforms:<br>
          <ul>
            <li>Python v2.7+ under Debian/Ubuntu</li>
            <li>Python for Android (Py4A) app r5+ / Scripting Layer for
              Android (SL4A) app r6+</li>
            <li>Python-mini v2.7+ under OpenWRT 12.09+<br>
            </li>
          </ul>
        </div>
        <div>... to test the following Commotion implementations,
          respectively (where each is enabled by the user, not by the
          Python script):<br>
          <ul>
            <li>commotion-mesh-applet<br>
            </li>
            <li>Mesh Tether app<br>
            </li>
            <li>
              Commotion-OpenWRT DR1, with <b>python</b>, <b>python-json</b>,
              and <b>olsrd-mod-jsoninfo</b> modules installed<br>
            </li>
          </ul>
        </div>
        <div>Questions about how to proceed:<br>
          <ul>
            <li>Whether to proceed with Python-based testing framework? 
              I tried to heavily leverage the cross-platform
              compatibility, but is it worthwhile?</li>
          </ul>
        </div>
      </div>
    </blockquote>
    <blockquote
cite="mid:CADSh-SMDToMuum4XyJ=jDwk0LxD5OW7fdWwFw2v3EEzVoGiLxQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <ul>
            <li>The Python for Android implementation chosen, Py4A, is
              only Python v2.6.  Is having Python v2.7 on Android worth
              possibly compiling it into a custom APK?</li>
            <li>Many of the desired test vectors, e.g. throughput
              testing, require the test run simultaneously on at least 2
              nodes.  It's pretty easy to write a crude server in Python
              to function as one half of a throughput test, but does the
              complexity of running different Python scripts on
              different nodes simultaneously become unreasonable</li>
          </ul>
        </div>
      </div>
    </blockquote>
    Not at all, I think that it is necessary to have different nodes
    running tests simultaneously. In most of the openWRT testing
    situations we run currently, we have client devices running
    simultaneously to elucidate information about the mesh nodes. <br>
    <blockquote
cite="mid:CADSh-SMDToMuum4XyJ=jDwk0LxD5OW7fdWwFw2v3EEzVoGiLxQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <ul>
            <li>The python-mini module for OpenWRT chews up 1.5Mbytes of
              flash, and it doesn't include unittest by default.  This
              unfortunately appears to be <i>too much already</i>; it
              wouldn't fit on a Nanostation flash w/o removing lots of
              stuff.  Maybe this size could be trimmed down by modifying
              the python-mini package's Makefile, or by distributing
              test scripts in bytecode form to OpenWRT nodes.<br>
            </li>
          </ul>
        </div>
      </div>
    </blockquote>
    I think that loading python on to openWRT nodes is impractical.
    Having client devices running tests over the mesh with possible
    on-node analytics running for later collection will give us a good
    idea of QOS without having to load down the OpenWRT nodes, and as
    such, change their performance. We will not get the same level of
    detail as the android or desktop nodes, but it is really the best we
    can do while maintaining an accurate image of the nodes performance.<br>
    <br>
    <blockquote
cite="mid:CADSh-SMDToMuum4XyJ=jDwk0LxD5OW7fdWwFw2v3EEzVoGiLxQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <ul>
            <li>
            </li>
          </ul>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Fri, Mar 15, 2013 at 10:14 PM,
          Andrew Reynolds <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:andrew@opentechinstitute.org" target="_blank">andrew@opentechinstitute.org</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">It sounds
            reasonable. Could you sketch out what you have in mind? How<br>
            much of the network setup were you thinking of building into
            the test<br>
            framework vs. simply triggering and testing?<br>
            <span class="HOEnZb"><font color="#888888"><br>
                -andrew<br>
              </font></span>
            <div class="HOEnZb">
              <div class="h5"><br>
                On 03/15/2013 02:48 PM, Ben West wrote:<br>
                > Hi All,<br>
                ><br>
                > In lieu of recent progress towards getting
                Commotion to a working state on<br>
                > Android, Ubuntu/Debian. and now possibly OSX, what
                thoughts about building<br>
                > a simple and (to whatever degree feasible)
                cross-platform testing framework<br>
                > in Python?<br>
                ><br>
                > The general idea is that python scripts could be
                used to start hitting the<br>
                > test vectors listed here (note the server appears
                to be really slow):<br>
                ><br>
                > <a moz-do-not-send="true"
href="https://code.commotionwireless.net/projects/commotion/wiki/Testing#Mesh-Routing-Tech-Evaluations"
                  target="_blank">https://code.commotionwireless.net/projects/commotion/wiki/Testing#Mesh-Routing-Tech-Evaluations</a><br>
                > <a moz-do-not-send="true"
href="https://code.commotionwireless.net/projects/commotion/wiki/Testing#Testbed-Requirements-based-on-test-suite-defined-above"
                  target="_blank">https://code.commotionwireless.net/projects/commotion/wiki/Testing#Testbed-Requirements-based-on-test-suite-defined-above</a><br>
                > <a moz-do-not-send="true"
href="https://code.commotionwireless.net/projects/commotion/wiki/Testing#Release-Candidate-Test-Regimen"
                  target="_blank">https://code.commotionwireless.net/projects/commotion/wiki/Testing#Release-Candidate-Test-Regimen</a><br>
                ><br>
                > That is, assuming Ubuntu/Debian/OSX's python
                support as a starting point,<br>
                > could these lighweight python implementations allow
                for some unified test<br>
                > scripts across platforms?<br>
                ><br>
                > <a moz-do-not-send="true"
                  href="http://qpython.com/" target="_blank">http://qpython.com/</a>
                (for Android)<br>
                > <a moz-do-not-send="true"
                  href="https://dev.openwrt.org/browser/packages/lang/python/Makefile"
                  target="_blank">https://dev.openwrt.org/browser/packages/lang/python/Makefile</a>
                (for OpenWRT,<br>
                > to be compiled as module)<br>
                ><br>
                > Has anyone on the list had good experience with
                these Python<br>
                > implementations?<br>
                ><br>
                > My original thought for such testing scripts was to
                do them in shell<br>
                > scripting, but I'm guessing Python would be easier
                and more powerful.<br>
                ><br>
                ><br>
                ><br>
              </div>
            </div>
            <div class="HOEnZb">
              <div class="h5">>
                _______________________________________________<br>
                > Commotion-dev mailing list<br>
                > <a moz-do-not-send="true"
                  href="mailto:Commotion-dev@lists.chambana.net">Commotion-dev@lists.chambana.net</a><br>
                > <a moz-do-not-send="true"
                  href="https://lists.chambana.net/mailman/listinfo/commotion-dev"
                  target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-dev</a><br>
                ><br>
                <br>
                <br>
              </div>
            </div>
            <br>
            _______________________________________________<br>
            Commotion-dev mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:Commotion-dev@lists.chambana.net">Commotion-dev@lists.chambana.net</a><br>
            <a moz-do-not-send="true"
              href="https://lists.chambana.net/mailman/listinfo/commotion-dev"
              target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-dev</a><br>
            <br>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <br>
        -- <br>
        Ben West
        <div><a moz-do-not-send="true" href="http://gowasabi.net"
            target="_blank">http://gowasabi.net</a><br>
          <a moz-do-not-send="true" href="mailto:ben@gowasabi.net"
            target="_blank">ben@gowasabi.net</a><br>
          314-246-9434<br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Commotion-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Commotion-dev@lists.chambana.net">Commotion-dev@lists.chambana.net</a>
<a class="moz-txt-link-freetext" href="https://lists.chambana.net/mailman/listinfo/commotion-dev">https://lists.chambana.net/mailman/listinfo/commotion-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>