Commit 859a9986 authored by Leigh B. Stoller's avatar Leigh B. Stoller

Address comments on start command and batch system changes, and sync

server additions, made by Eric, Tim and Jay.
parent c747d4eb
......@@ -5,7 +5,7 @@
*/
/*
* This ia program agent to manage programs from the event system.
* This is a program agent to manage programs from the event system.
*
* You can start, stop, and kill (signal) programs.
*/
......
......@@ -28,6 +28,7 @@ ETCDIR = $(DESTDIR)$(CLIENT_ETCDIR)
BINDIR = $(DESTDIR)$(CLIENT_BINDIR)
VARDIR = $(DESTDIR)$(CLIENT_VARDIR)
RCDIR = $(DESTDIR)/usr/local/etc/rc.d
TBBINDIR = $(DESTDIR)/usr/testbed/bin
INSTALL = /usr/bin/install -c
install:
......@@ -36,7 +37,7 @@ install:
@echo "directory afterwards."
local-install: path-install local-script-install
local-install: path-install local-script-install symlinks
remote-install: path-install remote-script-install
control-install: path-install control-script-install
......@@ -55,6 +56,7 @@ dir-install:
$(INSTALL) -m 755 -o root -g wheel -d $(VARDIR)/logs
$(INSTALL) -m 755 -o root -g wheel -d $(VARDIR)/boot
$(INSTALL) -m 755 -o root -g wheel -d $(VARDIR)/lock
$(INSTALL) -m 755 -o root -g wheel -d $(TBBINDIR)
path-install: dir-install
$(INSTALL) -m 755 $(SRCDIR)/paths.pm $(ETCDIR)/paths.pm
......@@ -69,7 +71,13 @@ common-script-install: dir-install vnodesetup
$(INSTALL) -m 755 $(SRCDIR)/update $(BINDIR)/update
$(INSTALL) -m 755 vnodesetup $(BINDIR)/vnodesetup
$(INSTALL) -m 755 $(SRCDIR)/bootvnodes $(BINDIR)/bootvnodes
$(INSTALL) -m 755 $(SRCDIR)/batchcmddone $(BINDIR)/batchcmddone
$(INSTALL) -m 755 $(SRCDIR)/startcmddone $(BINDIR)/startcmddone
symlinks: dir-install
rm -f $(TBBINDIR)/tevc
ln -s $(BINDIR)/tevc $(TBBINDIR)/tevc
rm -f $(TBBINDIR)/emulab-sync
ln -s $(BINDIR)/emulab-sync $(TBBINDIR)/emulab-sync
local-script-install: common-script-install
$(INSTALL) -m 755 $(SRCDIR)/bootsetup $(BINDIR)/bootsetup
......
......@@ -7,11 +7,11 @@
use English;
#
# Report that batch command for this node is done. Report status.
# Report that start command for this node is done. Report status.
#
sub usage()
{
print "Usage: batchcmddone <status>\n";
print "Usage: startcmddone <status>\n";
exit(1);
}
my $stat;
......
......@@ -730,10 +730,8 @@
rerun your experiment from scratch, but without the added expense
of a swapin and swapout. In other words, the nodes that are
currently allocated to your experiment are all rebooted, and the
experiment startup state is cleared. This includes the
<a href="#SWS-6">ready bits</a>, the boot status in the web page,
and the <a href="#SWS-4">startup command status</a>. In addition,
the event scheduler for the experiment is restarted, and your event
experiment startup state is cleared.
The event scheduler for the experiment is restarted, and your event
sequence is replayed again. Note that your rpms and tarfiles are
<b>not</b> installed again. Replay is obviously faster than
swapout/swapin, and has the added benefit that you will not run
......@@ -1062,7 +1060,7 @@
RPM installation) has completed. The exit status of the script (or
program) is reported back and is made available for you to view in
Experiment Information link in the menu at your left. The Emulab
NS extension <tt>tb-set-node-startup</tt> is used in the NS file
NS extension <tt>tb-set-node-startcmd</tt> is used in the NS file
to specify the path of the script (or program) to run. You may
specify a different program for each node in the experiment.
</p>
......@@ -1090,22 +1088,11 @@
<font size='+1'><b>How does my software determine when other nodes in my
experiment are ready?</b></font>
<p>
If your application requires synchronization to determine when all
of the nodes in your experiment have started up and are ready to
proceed, then you can use the Testbed's <i>ready bits</i>
mechanism. The ready bits are really just a way of determining how
many nodes have issued the <b>ready</b> command, and is returned
to the application as a simple N of M string, where N is the
number that have reported in, and M is the total number of nodes
in the experiment. Applications can use this as a very simplistic
form of barrier synchronization, albeit one that can be used just
once and one that does not actually block!
</p>
<p>
Use of the ready bits is described in more detail in the <a href =
"tutorial/tutorial.php3">Emulab Tutorial</a> and in the <a href =
"doc/docwrapper.php3?docname=tmcd.html"> Testbed Master Control
Daemon</a> documentation.
If your application requires synchronization amongst your nodes,
you may use the Emulab provided synchronization server, which
provides a very simple form of barrier synchronization. Use of the
synchronization server is described in more detail in the <a href =
"tutorial/tutorial.php3#SyncServer">Emulab Tutorial</a>.
</p>
<li><a NAME="SWS-7"></a>
......
......@@ -1014,7 +1014,6 @@ function SHOWNODES($pid, $eid) {
<th>Node<br>Status</th>
<th>Hours<br>Idle[<b>1</b>]</th>
<th>Startup<br>Status[<b>2</b>]</th>
<th>Ready<br>Status[<b>3</b>]</th>
</tr>\n";
$sort = "type,priority";
......@@ -1043,7 +1042,6 @@ function SHOWNODES($pid, $eid) {
$type = $row[type];
$def_boot_osid = $row[def_boot_osid];
$startstatus = $row[startstatus];
$readystatus = $row[ready];
$status = $row[nodestatus];
$bootstate = $row[eventstate];
$idlehours = TBGetNodeIdleTime($node_id);
......@@ -1057,10 +1055,6 @@ function SHOWNODES($pid, $eid) {
if (!$vname)
$vname = "--";
if ($readystatus)
$readylabel = "Yes";
else
$readylabel = "No";
echo "<tr>
<td><A href='shownode.php3?node_id=$node_id'>$node_id</a>
......@@ -1083,7 +1077,6 @@ function SHOWNODES($pid, $eid) {
echo " <td>$idlestr</td>
<td align=center>$startstatus</td>
<td align=center>$readylabel</td>
</tr>\n";
}
echo "</table>\n";
......@@ -1093,7 +1086,6 @@ function SHOWNODES($pid, $eid) {
the node has not reported on its proper schedule.
<li>Exit value of the node startup command. A value of
666 indicates a testbed internal error.
<li>User application ready status, reported via TMCC.
</ol>
</blockquote></blockquote></blockquote></h4>\n";
}
......
......@@ -400,6 +400,7 @@ example:
<p>
<h3>
<a NAME="ProgramObjects"></a>
Program Objects
</h3>
......
set ns [new Simulator]
source tb_compat.tcl
# Two nodes
set nodeA [$ns node]
set nodeB [$ns node]
# A link
$ns duplex-link $nodeA $nodeB 100Mb 0ms DropTail
# Set the OS.
tb-set-node-os $nodeA FBSD-STD
tb-set-node-os $nodeB FBSD-STD
tb-set-node-os $nodeB RHL-STD
tb-set-node-rpms $nodeA /proj/testbed/rpms/silly-1.0-1.i386-freebsd.rpm
tb-set-node-rpms $nodeB /proj/testbed/rpms/silly-1.0-1.i386-freebsd.rpm
# Load our software.
tb-set-node-tarfiles $nodeA /usr/site /proj/testbed/tarfiles/silly.tar.gz
tb-set-node-tarfiles $nodeB /usr/site /proj/testbed/tarfiles/silly.tar.gz
tb-set-node-startup $nodeA /usr/site/bin/run-silly
tb-set-node-startup $nodeB /usr/site/bin/run-silly
# Set the commands to run
tb-set-node-startcmd $nodeA "/usr/site/bin/run-silly >& /tmp/foo.log"
tb-set-node-startcmd $nodeB "/usr/site/bin/run-silly >& /tmp/foo.log"
$ns run
......@@ -323,12 +323,12 @@ tb-set-node-rpms $node0 rpm1 rpm2 rpm3
</ul>
<h4>tb-set-node-startup</h4>
<h4>tb-set-node-startcmd</h4>
<pre>
tb-set-node-startup <i>node</i> <i>startupcmd</i>
tb-set-node-startcmd <i>node</i> <i>startupcmd</i>
tb-set-node-startup $node0 {mystart.sh -a}
tb-set-node-startcmd $node0 {mystart.sh -a >& /tmp/node0.log}
</pre>
<p>Notes:
......
<!--
EMULAB-COPYRIGHT
Copyright (c) 2000-2002 University of Utah and the Flux Group.
Copyright (c) 2000-2003 University of Utah and the Flux Group.
All rights reserved.
-->
<center>
......@@ -8,7 +8,7 @@
</center>
If you <em>really</em> want to setup and manage routing entirely by
yourself, you can use the <tt>tb-set-node-startup</tt> command in your
yourself, you can use the <tt>tb-set-node-startcmd</tt> command in your
NS file to specify a per-node script in your home directory to set up
routing at boot time. You can use this startup script to setup either
static routes or to fire up a routing daemon. We do not recommend this
......@@ -23,7 +23,7 @@ to <i>router</i>. In order to get router to correctly forward packets
between client and server, you would add this line to your NS file:
<code><pre>
tb-set-node-startup $router /proj/pid/router-startup
tb-set-node-startcmd $router /proj/pid/router-startup
</pre></code>
This will make router run the <code>router-startup</code> script
......@@ -49,8 +49,8 @@ Now to get client and server to talk to each other through this router,
you would add these lines to your NS file:
<code><pre>
tb-set-node-startup $client /proj/pid/clientroutecmd
tb-set-node-startup $server /proj/pid/serverroutecmd
tb-set-node-startcmd $client /proj/pid/clientroutecmd
tb-set-node-startcmd $server /proj/pid/serverroutecmd
</pre></code>
This will have the client and the server each call a small script
......@@ -119,8 +119,8 @@ You can make a single script that will handle all end nodes, by replacing
and specifying the router in your NS file:
<code><pre>
tb-set-node-startup $clientA {/proj/pid/router-startup router0}
tb-set-node-startup $clientB {/proj/pid/router-startup router1}
tb-set-node-startcmd $clientA {/proj/pid/router-startup router0}
tb-set-node-startcmd $clientB {/proj/pid/router-startup router1}
</pre></code>
For multiple routers, the startup script for each router will need to
......
This diff is collapsed.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment