Megatest

owlfs for example) without being specialized for any specific problem
space. Megatest in of itself does not know what constitutes a PASS or FAIL
of a test or task. In most cases megatest is best used in conjunction with
logpro or a similar tool to parse, analyze and decide on the test outcome.</p></div>
<div class="ulist"><ul>
<li>
<p>
Self-checking - make it as easy as possible to write self-checking
   tests (as opposed to using deltas, i.e. tests that compare with a
   previous measurement to deterine PASS/FAIL).
</p>
</li>
<li>
<p>
Traceable - environment variables, host OS and other possibly
   influential variables are captured and kept recorded.
</p>
</li>
<li>
<p>
Immutable - once a test is run it cannot be easily overwritten or
   modified accidentally.
</p>
</li>
<li>
<p>
Repeatable - test results can be recreated in the future using all
   the original variables.
</p>
</li>
<li>
<p>
Relocatable - the testsuite or automation area can be checked out
   and the tests run anywhere in the disk hierarchy.
</p>
</li>
<li>
<p>
Encapsulated - the tests run in self-contained directories and all
   inputs and outputs to the process can be found in the run areas.
</p>
</li>
<li>
<p>
Deployable - a testsuite is self-contained and can be bundled with
   a software project and easily used by others with little to no
   setup burden.
</p>
</li>
</ul></div>
</div>
</div>
<div class="sect1">
<h2 id="_megatest_architecture">Megatest Architecture</h2>
<div class="sectionbody">
<div class="sect2">
<h3 id="_data_separation">Data separation</h3>
<div class="paragraph"><p>All data to specify the tests and configure the system is stored in
plain text config files. All system state is stored in an sqlite3
database.</p></div>
</div>
<div class="sect2">
<h3 id="_distributed_compute">Distributed Compute</h3>
<div class="paragraph"><p>Tests are launched using the launching system available for the
distributed compute platform in use. A template script is provided
which can launch jobs on local and remote Linux hosts. Currently
megatest uses the network filesystem to call home to your master
sqlite3 database. Megatest has been used with the Intel Netbatch and
lsf (also known as openlava) batch systems and it should be
straightforward to use it with other similar systems.</p></div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_overview">Overview</h2>
<div class="sectionbody">
<div class="sect2">
<h3 id="_stand_alone_megatest_area">Stand-alone Megatest Area</h3>
<div class="paragraph"><p>A single, stand-alone, Megatest based testsuite or "area" is
sufficient for most validation, automation and build problems.</p></div>
<div class="imageblock">
<div class="content">
<img src="megatest-stand-alone-area.png" alt="Static">
</div>
</div>
<div class="paragraph"><p>Megatest is designed as a distributed or decoupled system. This means
you can run the areas stand-alone with no additional
infrastructure. I.e. there are no databases, web servers or other
centralized resources needed. However as your needs grow you can
integrate multiple areas into a bigger system.</p></div>
<div class="sect3">
<h4 id="_component_descriptions">Component Descriptions</h4>
<div class="olist arabic"><ol class="arabic">
<li>
<p>
Multi-area dashboard and xterm. A gui (the dashboard) is usually the
  best option for controlling and launching runs but all operations
  can also be done from the commandline. Note: The not yet released
  multi-area dashboard replaces the old dashboard for browsing and
  controlling runs but for managing a single area the old dashboard
  works very well.
</p>
</li>
<li>
<p>
Area/testsuite. This is your testsuite or automation definition and
  consists of the information in megatest.config, runconfigs.config
  and your testconfigs along with any custom scripting that can&#8217;t be
  done with the native Megatest features.
</p>
</li>
<li>
<p>
If your testsuite or build automation is too large to run on a
  single instance you can distribute your jobs into a compute server
  pool. The only current requirements are password-less ssh access and
  a network filesystem.
</p>
</li>
</ol></div>
</div>
</div>
<div class="sect2">
<h3 id="_full_system_architecture">Full System Architecture</h3>
<div class="imageblock">
<div class="content">
<img src="megatest-system-architecture.png" alt="Static">
</div>








</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_installation">Installation</h2>
<div class="sectionbody">

</div>
</div>
</div>
<div id="footnotes"><hr></div>
<div id="footer">
<div id="footer-text">
Version 1.0<br>
Last updated 2018-11-27 13:07:36 PST
</div>
</div>
</body>
</html>

resources to make writing a suite of tests and tasks for implementing
continuous build for software, design engineering or process control (via
owlfs for example) without being specialized for any specific problem
space. Megatest in of itself does not know what constitutes a PASS or FAIL
of a test or task. In most cases megatest is best used in conjunction with
logpro or a similar tool to parse, analyze and decide on the test outcome.

 * Self-checking - make it as easy as possible to write self-checking
   tests (as opposed to using deltas, i.e. tests that compare with a
   previous measurement to deterine PASS/FAIL).

 * Traceable - environment variables, host OS and other possibly
   influential variables are captured and kept recorded.

 * Immutable - once a test is run it cannot be easily overwritten or
   modified accidentally.

 * Repeatable - test results can be recreated in the future using all
   the original variables.

 * Relocatable - the testsuite or automation area can be checked out
   and the tests run anywhere in the disk hierarchy.

 * Encapsulated - the tests run in self-contained directories and all
   inputs and outputs to the process can be found in the run areas.

 * Deployable - a testsuite is self-contained and can be bundled with
   a software project and easily used by others with little to no
   setup burden.

Megatest Architecture
---------------------

Data separation
~~~~~~~~~~~~~~~

All data to specify the tests and configure the system is stored in
plain text config files. All system state is stored in an sqlite3
database.

Distributed Compute
~~~~~~~~~~~~~~~~~~~

Tests are launched using the launching system available for the
distributed compute platform in use. A template script is provided
which can launch jobs on local and remote Linux hosts. Currently
megatest uses the network filesystem to call home to your master
sqlite3 database. Megatest has been used with the Intel Netbatch and
lsf (also known as openlava) batch systems and it should be
straightforward to use it with other similar systems.

include::overview.txt[]

include::installation.txt[]

include::getting_started.txt[]