* Prior to this commit, libplab depended on db state to create slivers
    and slices.  Now it can be done using the regular command line tools
    without the metadata in the db.  This makes development and debugging
    much easier and allows us to use the command-line tools even if state has
    been cleared out of the db (i.e., for sliver garbage collection).
  * Add support for sliver start/stop/restart via the v4 NM.
  * Some support for sliver garbage collection.
  * Various other improvements and cleanup.

where the current stuff goes (datastore, nsfile, etc.). The other
subdir is called "records" and will be populated with stuff that we
currently put into the archive (the contents of the experiment
directory).

There is a record for each run, currently named XXX,YY where XXX is
the instance ID and YY is the run number. I plan to add an XML file to
map these to the symbolic names, but these are not required to be
unique, which is why the directories are not named with them.

datastore directory (append "/*").

Also fix bug that was causing pnode days to go negative for some
ranges.

experiment underlying a template. Rather then using the experiment directory
we use the template directory in /proj/$pid/templates ...

  since we import a bunch of dumped db state from the outer to the inner db.
  Added/removed columns in the schema misalign row data, causing much chaos.

tbsetup/elabinelab.in - Dump and send the outer db schema with the db state.
  Runs mysqldump just like schemacheck does.

tmcd/common/config/rc.mkelab - Add the schema check using schemadiff.

utils/schemadiff - Add an option to ignore table creates and drops.

in the cross-correlation checks. This should completely take care
of detecting the faulty TCP runs we saw last week.

The new user must be active and a member of the project. The old project
leader is left in the project with local_root permissions. This avoids the
problem of what to do with existing experiments, etc. Usage:

	wap changeleader testbed stoller

a locally modifed version of CVS that does a couple of extra things. The
hacks are quite simple and currently on users. Briefly, there is a new
config file option to specify a program to run when the tag operation is
complete (similar to a module hook for rtag), and in tag.c I run that hook.

Check out a sandbox as before:

  cvs -d ops.emulab.net:/proj/$pid/templates/XXXXX/cvsrepo rtag mytag XXXXX

To create a new template (along the trunk), use the tag operation instead:

	cd sandbox
	cvs tag mtag

and what for the email that says the template is created. You can
continue to work along the trunk in this manner, although note that
the .template file is changing (by the backend commit), and you might
find it less distriacting to do a cvs update each time.

To work along a branch:

	cd sandbox
	cvs tag -r existing_tag -b newtag1
        cvs update -r newtag
        make changes and commits
	cvs tag newtag2

When working along branched you will want to do a cvs update to get
the .template file in sync.

"rtag" directive to initiate template modify operations. So, to get started
you do a checkout:

  cvs -d ops.emulab.net:/proj/$pid/templates/XXXXX/cvsrepo checkout XXXXX

where XXXXX is the part of the guid (10000/1) before the slash. Might try
and roll all templates into a single project wide repo at some point, to
avoid the extraneous path stuff, but didn't want to worry that just yet.

Okay, so have a checkout. You can work along the trunk, doing commits. To
create a new template (a modify of the existing template), you tag the tree
using rtag:

  cvs -d ops.emulab.net:/proj/$pid/templates/XXXXX/cvsrepo rtag mytag XXXXX

A template modify is started at the end, and you should probably wait for
email before continuing. Eventually I will need to add locking of some
kind, but I have to do the modify in the background, or else I get deadlock
cause cvs keeps the repo locked, and the modify also needs to access it.

Each time you tag along the trunk, you get a modified template, which in
the history diagram looks like:

  10000/1 --> 10000/2 --> 10000/3 ...

If you want to branch, say at 10000/2 you can create a branch tag using rtag:

  cvs -d [cut] rtag -r T10000/2 -b mytag2 XXXXX

You can also use your own tags for -r option, but I also create a TXXXXX/YY
tag at each template modify, which is easy to remember.

Then update your sandbox to the new branch, commit changes along that
branch, and then later use rtag again to initiate a template modify
operation:

  cvs update -r mytag2
  cvs commit ...
  cvs -d [cut] rtag -r mytag2 mytag3 XXXXX

And now the history diagram looks like:

  10000/1 --> 10000/2 --> 10000/3 ...
                |
                |
                -> 10000/4 ...

You should be able to mix interaction via the web with interaction via the
cvs interface. I've tested it, although not extensively.

From: Keith Sklower <sklower@vangogh.CS.Berkeley.EDU>
To: testbed-ops@flux.utah.edu
Subject: another emulab-in-emulab bugfix for non-routeable control nets
Date: Thu, 5 Jul 2007 15:12:09 -0700 (PDT)

If one is at ucb or isi or cornell, the inner ops and boss can't retrieve
the flyspray or wiki sources from www.emulab.net;
this shows up in install/ops-install.in.

I'm pretty sure I described this problem before but here's an
actual patch (which I just tried, and know at least to install
rather than abort rc.mkelab):

and ptop files. They are intended for rolling distributions of historical
topology information.

check-top is essentially a full perl parser for top and ptop files, and
should make it relatively easy to convert to other file formats.

the typo for the new option --nopeerserver.

Fixed a bug when use-magent was set to 2 (Use magent but use iperfd as the peer server). peerserverport was set to 0 in this case which made the magent unable to connect to other magents. Now there is a seperate --nopeerserver option.

script (moving average + cross-correlation) takes just over a minute on a
pc3000 for verifying a 800 MB TCP Iperf transfer on flexlab.

A little tweak for the better - removed scaling of max delay values (which used to depend on packet size).

the value is and wraps it appropriately in the query.

complicated because we use one big huge query to filter out as much as we
can in the db to speed things up, but there is already a search option
that restricts based on pid/eid.  Thus, if pid/eid search is enabled, we
have to do an additional postfilter pass to filter out nodes that are not
both status='up' and not in hwdown.

but if the child thread calls exit(-1) from fatal, the frisbee process
exits, but with a code of zero; i.e., the child exit code is lost.
Granted, a multi-threaded program should not be calling exit willy-nilly,
but it does so we deal with it as follows.

Since the child should never exit during normal operation (we always
kill it), if it does exit we know there is a problem.  So, we catch
all exits and if it is the child, we set a flag.  The parent thread
will see this and exit with an error.

Since I don't understand this fully, I am making it a FreeBSD-only
thing for now.

Setting the sql mode for the database session to 'STRCIT_ALL'.
This is to handle the database setting difference between mysql on Ops
and mysql on DataPository.

Added an extra layer of protection to prevent to-and-fro switching
between different nodes on a site due to CPU USAGE difference.
Previously if a node has less cpu load than current best node (discounted
by a threshold of 10). Now this has to happen 2 times consecutively
for the switching to happen.

Added randomness for initial starting of bw probes scheduled by
automanagerclient.

Cross-correlation calculation now takes less than 15 sec for a 15 minute
TCP transfer - averaging time is still huge though...

Added documentation to explain what is going on and how a run
is declared correct/incorrect.