/usr/share/doc/lava-server-doc/html/multinode.html is in lava-server-doc 2014.09.1-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Multi-Node LAVA — LAVA Server 2014.09.1 documentation</title>
<link rel="stylesheet" href="_static/default.css" type="text/css" />
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: './',
VERSION: '2014.09.1',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="_static/jquery.js"></script>
<script type="text/javascript" src="_static/underscore.js"></script>
<script type="text/javascript" src="_static/doctools.js"></script>
<link rel="shortcut icon" href="_static/favicon.ico"/>
<link rel="top" title="LAVA Server 2014.09.1 documentation" href="index.html" />
<link rel="next" title="MultiNode API" href="multinodeapi.html" />
<link rel="prev" title="LAVA Hacking Sessions" href="hacking-session.html" />
</head>
<body>
<div class="related">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="genindex.html" title="General Index"
accesskey="I">index</a></li>
<li class="right" >
<a href="multinodeapi.html" title="MultiNode API"
accesskey="N">next</a> |</li>
<li class="right" >
<a href="hacking-session.html" title="LAVA Hacking Sessions"
accesskey="P">previous</a> |</li>
<li><a href="index.html">LAVA Server 2014.09.1 documentation</a> »</li>
</ul>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body">
<div class="section" id="multi-node-lava">
<span id="multinode"></span><span id="index-0"></span><h1>Multi-Node LAVA<a class="headerlink" href="#multi-node-lava" title="Permalink to this headline">¶</a></h1>
<p>LAVA multi-node support allows users to use LAVA to schedule, synchronise and
combine the results from tests that span multiple targets. Jobs can be arranged
as groups of devices (of any type) and devices within a group can operate
independently or use the MultiNode API to communicate with other devices in the
same group during tests.</p>
<p>Within a MultiNode group, devices are assigned a role and a <tt class="docutils literal"><span class="pre">count</span></tt> of devices to
include into that role. Each role has a <tt class="docutils literal"><span class="pre">device_type</span></tt> and any number of roles can
have the same <tt class="docutils literal"><span class="pre">device_type</span></tt>. Each role can be assigned device <tt class="docutils literal"><span class="pre">tags</span></tt>.</p>
<p>Once roles are defined, actions (including test images and test definitions) can be marked
as applying to specific roles (if no role is specified, all roles use the action).</p>
<p>A role can be marked as <cite>slave</cite> (thanks to the <tt class="docutils literal"><span class="pre">is_slave</span></tt> argument). A
slave role will not be booted by LAVA directly but by another device within the
MultiNode group.</p>
<p>If insufficient boards exist to meet the combined requirements of all the roles specified
in the job, the job will be rejected.</p>
<p>If there are not enough idle boards of the relevant types to meet the combined requirements
of all the roles specified in the job, the job waits in the Submitted queue until all
devices can be allocated.</p>
<p>Once each board has booted the test image, the MultiNode API will be available for use within
the test definition in the default PATH.</p>
<div class="toctree-wrapper compound">
<ul>
<li class="toctree-l1"><a class="reference internal" href="multinodeapi.html">MultiNode API</a><ul>
<li class="toctree-l2"><a class="reference internal" href="multinodeapi.html#lava-self">lava-self</a></li>
<li class="toctree-l2"><a class="reference internal" href="multinodeapi.html#lava-role">lava-role</a></li>
<li class="toctree-l2"><a class="reference internal" href="multinodeapi.html#lava-group">lava-group</a></li>
<li class="toctree-l2"><a class="reference internal" href="multinodeapi.html#lava-send">lava-send</a></li>
<li class="toctree-l2"><a class="reference internal" href="multinodeapi.html#lava-wait">lava-wait</a></li>
<li class="toctree-l2"><a class="reference internal" href="multinodeapi.html#lava-wait-all">lava-wait-all</a></li>
<li class="toctree-l2"><a class="reference internal" href="multinodeapi.html#lava-sync">lava-sync</a></li>
<li class="toctree-l2"><a class="reference internal" href="multinodeapi.html#lava-network">lava-network</a></li>
<li class="toctree-l2"><a class="reference internal" href="multinodeapi.html#example-1-simple-client-server-multi-node-test">Example 1: simple client-server multi-node test</a></li>
<li class="toctree-l2"><a class="reference internal" href="multinodeapi.html#example-2-variable-number-of-clients">Example 2: variable number of clients</a></li>
<li class="toctree-l2"><a class="reference internal" href="multinodeapi.html#example-3-peer-to-peer-application">Example 3: peer-to-peer application</a></li>
<li class="toctree-l2"><a class="reference internal" href="multinodeapi.html#example-4-using-lava-network">Example 4: using lava-network</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="debugging.html">Debugging LAVA test definitions</a><ul>
<li class="toctree-l2"><a class="reference internal" href="debugging.html#convert-multi-node-jobs-to-single-node">Convert Multi-Node jobs to single node</a></li>
<li class="toctree-l2"><a class="reference internal" href="debugging.html#always-use-set-x-in-wrapper-scripts">Always use set -x in wrapper scripts</a></li>
<li class="toctree-l2"><a class="reference internal" href="debugging.html#avoid-using-shell-operators-in-yaml-lines">Avoid using shell operators in YAML lines</a></li>
<li class="toctree-l2"><a class="reference internal" href="debugging.html#check-that-your-message-id-labels-are-consistent">Check that your message ID labels are consistent</a></li>
<li class="toctree-l2"><a class="reference internal" href="debugging.html#test-your-result-parsers">Test your result parsers</a></li>
<li class="toctree-l2"><a class="reference internal" href="debugging.html#be-obsessive-about-paths-and-scripts">Be obsessive about paths and scripts</a></li>
<li class="toctree-l2"><a class="reference internal" href="debugging.html#a-failed-test-is-not-necessarily-a-bug-in-the-test">A failed test is not necessarily a bug in the test</a></li>
<li class="toctree-l2"><a class="reference internal" href="debugging.html#check-your-json-files">Check your JSON files</a></li>
</ul>
</li>
</ul>
</div>
<div class="section" id="hardware-requirements-and-virtualisation">
<h2>Hardware requirements and virtualisation<a class="headerlink" href="#hardware-requirements-and-virtualisation" title="Permalink to this headline">¶</a></h2>
<p>Multi-Node is explicitly about synchronising test operations across multiple boards and running
Multi-Node jobs on a particular instance will have implications for the workload of that instance.
This can become a particular problem if the instance is running on virtualised hardware with
shared I/O, a limited amount of RAM or a limited number of available cores.</p>
<p>e.g. Downloading, preparing and deploying test images can result in a lot of synchronous I/O and
if this instance is running the server and the dispatcher, this can cause the load on that machine
to rise significantly, possibly causing the server to become unresponsive.</p>
<p>It is strongly recommended that Multi-Node instances use a separate dispatcher running on
non-virtualised hardware so that the (possibly virtualised) server can continue to operate.</p>
<p>Also, consider the number of boards connected to any one dispatcher. MultiNode jobs will commonly
compress and decompress several test image files of several hundred megabytes at precisely the same
time. Even with a powerful multi-core machine, this has been shown to cause appreciable load. It
is worth considering matching the number of boards to the number of cores for parallel decompression
and matching the amount of available RAM to the number and size of test images which are likely to
be in use.</p>
</div>
<div class="section" id="extending-existing-lava-submissions">
<h2>Extending existing LAVA submissions<a class="headerlink" href="#extending-existing-lava-submissions" title="Permalink to this headline">¶</a></h2>
<p>To extend an existing JSON file to start a MultiNode job, some changes are required to define the
<tt class="docutils literal"><span class="pre">device_group</span></tt>. If all devices in the group are to use the same actions, simply create a single
role with a count for how many devices are necessary. Usually, a MultiNode job will need to assign
different test definitions to different boards and this is done by adding more roles, splitting the
number of devices between the differing roles and assigning different test definitions to each role.</p>
<p>If a MultiNode job includes devices of more than one <tt class="docutils literal"><span class="pre">device_type</span></tt>, there needs to be a role for
each different <tt class="docutils literal"><span class="pre">device_type</span></tt> so that an appropriate image can be deployed.</p>
<p>Where all roles share the same action (e.g. <tt class="docutils literal"><span class="pre">submit_results_on_host</span></tt>), omit the role parameter from
that action.</p>
<p>If more than one, but not all, roles share one particular action, that action will need to be repeated
within the JSON file, once for each role using that action.</p>
<div class="section" id="changes-to-submission-json">
<span id="changes-to-json"></span><h3>Changes to submission JSON<a class="headerlink" href="#changes-to-submission-json" title="Permalink to this headline">¶</a></h3>
<ol class="arabic simple">
<li><tt class="docutils literal"><span class="pre">device</span></tt> or <tt class="docutils literal"><span class="pre">device_type</span></tt> move into a <strong>device_group</strong> list</li>
<li>Each device type has a <tt class="docutils literal"><span class="pre">count</span></tt> assigned</li>
</ol>
<blockquote>
<div><ol class="arabic simple">
<li>If a <tt class="docutils literal"><span class="pre">device</span></tt> is specified directly, count needs to be one.</li>
<li>If <tt class="docutils literal"><span class="pre">device_type</span></tt> is used and count is larger than one, enough
devices will be allocated to match the count and all such devices will
have the same role and use the same commands and the same actions.</li>
</ol>
</div></blockquote>
<ol class="arabic simple" start="3">
<li>Add <a class="reference internal" href="glossary.html#term-device-tag"><em class="xref std std-term">device tag</em></a> to each role, if supported for the relevant devices.</li>
<li>If specific actions should only be used for particular roles, add a
role field to the parameters of the action.</li>
<li>If any action has no role specified, it will be actioned for all roles.</li>
</ol>
<p>Example JSON:</p>
<div class="highlight-python"><div class="highlight"><pre>{
"timeout": 900,
"job_name": "simple multinode job",
"logging_level": "INFO",
"device_group": [
{
"role": "omap4",
"count": 2,
"device_type": "panda",
"tags": [
"usb-flash"
]
},
{
"role": "omap3",
"count": 1,
"device_type": "beaglexm",
"tags": [
"audio-loopback"
]
}
],
</pre></div>
</div>
</div>
<div class="section" id="using-actions-for-particular-roles">
<span id="index-1"></span><h3>Using actions for particular roles<a class="headerlink" href="#using-actions-for-particular-roles" title="Permalink to this headline">¶</a></h3>
<p>Example JSON:</p>
<div class="highlight-python"><div class="highlight"><pre>"actions": [
{
"command": "deploy_linaro_image",
"parameters": {
"image": "file:///home/instance-manager/images/panda-raring_developer_20130529-347.img.gz",
"role": "omap4"
}
},
{
"command": "deploy_linaro_image",
"parameters": {
"image": "file:///home/instance-manager/images/beagle-ubuntu-desktop.img.gz",
"role": "omap3"
}
},
{
"command": "lava_test_shell",
"parameters": {
"testdef_repos": [
{
"git-repo": "git://git.linaro.org/qa/test-definitions.git",
"testdef": "ubuntu/smoke-tests-basic.yaml"
}
],
"timeout": 1800
}
}
}
</pre></div>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Consider using <a class="reference external" href="http://jsonlint.com">http://jsonlint.com</a> to check your JSON before submission.</p>
</div>
</div>
</div>
<div class="section" id="lava-multi-node-timeout-behaviour">
<span id="index-2"></span><h2>LAVA Multi-Node timeout behaviour<a class="headerlink" href="#lava-multi-node-timeout-behaviour" title="Permalink to this headline">¶</a></h2>
<p>The submitted JSON includes a timeout value - in single node LAVA, this is applied to each individual action
executed on the device under test (not for the entire job as a whole). i.e. the default timeout can be smaller
than any one individual timeout used in the JSON or internally within LAVA.</p>
<p>In Multi-Node LAVA, this timeout is also applied to individual polling operations, so an individual lava-sync
or a lava-wait will fail on any node which waits longer than the default timeout. The node will receive a failure
response.</p>
<div class="section" id="recommendations-on-timeouts">
<span id="timeouts"></span><h3>Recommendations on timeouts<a class="headerlink" href="#recommendations-on-timeouts" title="Permalink to this headline">¶</a></h3>
<p>MultiNode operations have implications for the timeout values used in JSON submissions. If one of the
synchronisation primitives times out, the sync will fail and the job itself will then time out.
One reason for a MultiNode job to timeout is if one or more boards in the group failed to boot the
test image correctly. In this situation, all the other boards will continue until the first
synchronisation call is made in the test definition for that board.</p>
<p>The time limit applied to a synchronisation primitive starts when the board makes the first request
to the Coordinator for that sync. Slower boards may well only get to that point in the test definition
after faster devices (especially KVM devices) have started their part of the sync and timed out
themselves.</p>
<p>Always review the top level timeout in the JSON submission - a value of 900 seconds (15 minutes) has
been common during testing. Excessive timeouts would prevent other jobs from using boards where the
waiting jobs have already failed due to a problem elsewhere in the group. If timeouts are too short,
jobs will fail unnecessarily.</p>
<div class="section" id="balancing-timeouts">
<h4>Balancing timeouts<a class="headerlink" href="#balancing-timeouts" title="Permalink to this headline">¶</a></h4>
<p>Individual actions and commands can have differing timeouts, so avoid the temptation to change the
default timeout when a particular action times out in a Multi-Node job. If a particular <tt class="docutils literal"><span class="pre">lava-test-shell</span></tt>
takes a long time, set an explicit timeout for that particular action:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="p">{</span>
<span class="s">"timeout"</span><span class="p">:</span> <span class="mi">900</span><span class="p">,</span>
<span class="s">"job_name"</span><span class="p">:</span> <span class="s">"netperf multinode tests"</span><span class="p">,</span>
<span class="s">"logging_level"</span><span class="p">:</span> <span class="s">"DEBUG"</span><span class="p">,</span>
<span class="p">}</span>
</pre></div>
</div>
<div class="highlight-python"><div class="highlight"><pre><span class="p">{</span>
<span class="s">"command"</span><span class="p">:</span> <span class="s">"lava_test_shell"</span><span class="p">,</span>
<span class="s">"parameters"</span><span class="p">:</span> <span class="p">{</span>
<span class="s">"testdef_repos"</span><span class="p">:</span> <span class="p">[</span>
<span class="p">{</span>
<span class="s">"git-repo"</span><span class="p">:</span> <span class="s">"git://git.linaro.org/people/guoqing.zhu/netperf-multinode.git"</span><span class="p">,</span>
<span class="s">"testdef"</span><span class="p">:</span> <span class="s">"netperf-multinode-c-network.yaml"</span>
<span class="p">}</span>
<span class="p">],</span>
<span class="s">"timeout"</span><span class="p">:</span> <span class="mi">2400</span><span class="p">,</span>
<span class="s">"role"</span><span class="p">:</span> <span class="s">"client"</span>
<span class="p">}</span>
<span class="p">},</span>
<span class="p">{</span>
<span class="s">"command"</span><span class="p">:</span> <span class="s">"lava_test_shell"</span><span class="p">,</span>
<span class="s">"parameters"</span><span class="p">:</span> <span class="p">{</span>
<span class="s">"testdef_repos"</span><span class="p">:</span> <span class="p">[</span>
<span class="p">{</span>
<span class="s">"git-repo"</span><span class="p">:</span> <span class="s">"git://git.linaro.org/people/guoqing.zhu/netperf-multinode.git"</span><span class="p">,</span>
<span class="s">"testdef"</span><span class="p">:</span> <span class="s">"netperf-multinode-s-network.yaml"</span>
<span class="p">}</span>
<span class="p">],</span>
<span class="s">"timeout"</span><span class="p">:</span> <span class="mi">1800</span><span class="p">,</span>
<span class="s">"role"</span><span class="p">:</span> <span class="s">"server"</span>
<span class="p">}</span>
<span class="p">},</span>
</pre></div>
</div>
</div>
</div>
</div>
<div class="section" id="running-a-server-on-the-device-under-test">
<h2>Running a server on the device-under-test<a class="headerlink" href="#running-a-server-on-the-device-under-test" title="Permalink to this headline">¶</a></h2>
<p>If this server process runs as a daemon, the test definition will need to define something for the device
under test to actually do or it will simply get to the end of the tests and reboot. For example, if the
number of operations is known, would be to batch up commands to the daemon, each batch being a test case.
If the server program can run without being daemonised, it would need to be possible to close it down
at the end of the test (normally this is the role of the sysadmin in charge of the server box itself).</p>
<div class="section" id="making-use-of-third-party-servers">
<h3>Making use of third party servers<a class="headerlink" href="#making-use-of-third-party-servers" title="Permalink to this headline">¶</a></h3>
<p>A common part of a MultiNode setup is to download components from third party servers but once the test
starts, latency and connectivity issues could interfere with the tests.</p>
</div>
<div class="section" id="using-wrapper-scripts">
<h3>Using wrapper scripts<a class="headerlink" href="#using-wrapper-scripts" title="Permalink to this headline">¶</a></h3>
<p>Wrapper scripts make it easier to test your definitions before submitting to LAVA.
The wrapper lives in a VCS repository which is specified as one of the testdef_repos and will be
available in the same directory structure as the original repository. A wrapper script also
helps the tests to fail early instead of trying to do the rest of the tests.</p>
</div>
</div>
<div class="section" id="booting-a-slave-device">
<h2>Booting a slave device<a class="headerlink" href="#booting-a-slave-device" title="Permalink to this headline">¶</a></h2>
<p>If one of the device is marked as <tt class="docutils literal"><span class="pre">slave</span></tt>, one device in the MultiNode group
will have to boot this device itself.
In order to synchronize the slave and the master, the MultiNode API is
used to send the following messages:</p>
<div class="highlight-python"><div class="highlight"><pre>* @slave sends "lava_ms_slave_data" with the needed boot information
* @master sends "lava_ms_ready" when it's ready to boot the slave
* @slave sends "lava_ms_boot" when he is ready to be booted
</pre></div>
</div>
<p>The master device is responsible for booting the slave device correctly. Once
booted, LAVA will take care of the slave device by running the tests on it.</p>
<p>This feature can be used to boot devices that requires specific pieces of
software in the boot process.
The boot process is then described in a test definition, running on the master device.</p>
</div>
<div class="section" id="multinode-result-bundles">
<h2>MultiNode Result Bundles<a class="headerlink" href="#multinode-result-bundles" title="Permalink to this headline">¶</a></h2>
<p>Results are generated by each device in the group. At submission time, one device in the group is
selected to run the job which gets the aggregated result bundle for the entire group.</p>
</div>
<div class="section" id="lava-coordinator-setup">
<span id="index-3"></span><h2>LAVA Coordinator setup<a class="headerlink" href="#lava-coordinator-setup" title="Permalink to this headline">¶</a></h2>
<p>Multi-Node LAVA requires a LAVA Coordinator which manages the messaging within a group of nodes involved in
a Multi-Node job set according to this API. The LAVA Coordinator is a singleton to which nodes need to connect
over a TCP port (default: 3079). A single LAVA Coordinator can manage groups from multiple instances.
If the network configuration uses a firewall, ensure that this port is open for connections from Multi-Node dispatchers.</p>
<p>If multiple coordinators are necessary on a single machine (e.g. to test different versions of the coordinator
during development), each coordinator needs to be configured for a different port.</p>
<p>If the dispatcher is installed on the same machine as the coordinator, the dispatcher can use the packaged
configuration file with the default hostname of <tt class="docutils literal"><span class="pre">localhost</span></tt>.</p>
<p>Each dispatcher then needs a copy of the LAVA Coordinator configuration file, modified to point back to the
hostname of the coordinator:</p>
<p>Example JSON, modified for a coordinator on a machine with a fully qualified domain name:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="p">{</span>
<span class="s">"port"</span><span class="p">:</span> <span class="mi">3079</span><span class="p">,</span>
<span class="s">"blocksize"</span><span class="p">:</span> <span class="mi">4096</span><span class="p">,</span>
<span class="s">"poll_delay"</span><span class="p">:</span> <span class="mi">3</span><span class="p">,</span>
<span class="s">"coordinator_hostname"</span><span class="p">:</span> <span class="s">"control.lab.org"</span>
<span class="p">}</span>
</pre></div>
</div>
<p>An IP address can be specified instead, if appropriate.</p>
<p>Each dispatcher needs to use the same port number and blocksize as is configured for the Coordinator
on the specified machine. The poll_delay is the number of seconds each node will wait before polling
the coordinator again.</p>
</div>
</div>
</div>
</div>
</div>
<div class="sphinxsidebar">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="index.html">
<img class="logo" src="_static/linaro.png" alt="Logo"/>
</a></p>
<h3><a href="index.html">Table Of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">Multi-Node LAVA</a><ul>
<li><a class="reference internal" href="#hardware-requirements-and-virtualisation">Hardware requirements and virtualisation</a></li>
<li><a class="reference internal" href="#extending-existing-lava-submissions">Extending existing LAVA submissions</a><ul>
<li><a class="reference internal" href="#changes-to-submission-json">Changes to submission JSON</a></li>
<li><a class="reference internal" href="#using-actions-for-particular-roles">Using actions for particular roles</a></li>
</ul>
</li>
<li><a class="reference internal" href="#lava-multi-node-timeout-behaviour">LAVA Multi-Node timeout behaviour</a><ul>
<li><a class="reference internal" href="#recommendations-on-timeouts">Recommendations on timeouts</a><ul>
<li><a class="reference internal" href="#balancing-timeouts">Balancing timeouts</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#running-a-server-on-the-device-under-test">Running a server on the device-under-test</a><ul>
<li><a class="reference internal" href="#making-use-of-third-party-servers">Making use of third party servers</a></li>
<li><a class="reference internal" href="#using-wrapper-scripts">Using wrapper scripts</a></li>
</ul>
</li>
<li><a class="reference internal" href="#booting-a-slave-device">Booting a slave device</a></li>
<li><a class="reference internal" href="#multinode-result-bundles">MultiNode Result Bundles</a></li>
<li><a class="reference internal" href="#lava-coordinator-setup">LAVA Coordinator setup</a></li>
</ul>
</li>
</ul>
<h4>Previous topic</h4>
<p class="topless"><a href="hacking-session.html"
title="previous chapter">LAVA Hacking Sessions</a></p>
<h4>Next topic</h4>
<p class="topless"><a href="multinodeapi.html"
title="next chapter">MultiNode API</a></p>
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="_sources/multinode.txt"
rel="nofollow">Show Source</a></li>
</ul>
<div id="searchbox" style="display: none">
<h3>Quick search</h3>
<form class="search" action="search.html" method="get">
<input type="text" name="q" />
<input type="submit" value="Go" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
<p class="searchtip" style="font-size: 90%">
Enter search terms or a module, class or function name.
</p>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="related">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="genindex.html" title="General Index"
>index</a></li>
<li class="right" >
<a href="multinodeapi.html" title="MultiNode API"
>next</a> |</li>
<li class="right" >
<a href="hacking-session.html" title="LAVA Hacking Sessions"
>previous</a> |</li>
<li><a href="index.html">LAVA Server 2014.09.1 documentation</a> »</li>
</ul>
</div>
<div class="footer">
© Copyright 2010-2014, Linaro Limited.
Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.3.
</div>
</body>
</html>
|