cvs repo from the template show page.

Updated felexdatasrv with new algorithm based on maximal clique. Also
added two new options:
 * specifying size=0 returns maximal clique
 * one can specify 'lat' or 'bw' as measurement types to consider
   (default is lat if not supplied)

figured out how to make it much simpler by creating a .app from my
little applescript widget. This bypasses a bug in Firefox wrt how
helper apps are invoked.

run, to store the original attributes, owner, group, and mtime/ctime/atime.

killed when the STOP event is received.

Also fix a couple of minor nits.

the delay setup!  Previously it was just killing it.

highest revision on the branch (or trunk) of the magic .template file,
since doing otherwise would seem to indicate an inconsistency in
what the user is doing. Why? Templates are modified via a tag
operation of the .template file, but splitting off can only be done
via a branch operation. Subsequent mods after a branch have to happen
along a straight line.

Also allow for tag moving to initiate a template modify since the
above implied error can be corrected by doing a cvs update, and then a
retag with the -F option to move the tag.

for each delegated slice we create, we set the 'delegations' attribute to
'utah_nmcontrol', the name of our nm-controller slice that has permissions
to talk to the NM.

Also, a few other fixes.

the run. Includes the bindings for the run and the metadata name/value
pairs. This is the same data that is dumped by template export, so
at this point template_export has been completely superceded by the
CVS repo.

  * 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.