GitLab

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

kicking around in my homedir for a while, but it really should be
in CVS.

It's updated to show *most* of our major switches - still doesn't have
some of the smaller experimental net switches or cisco6, however.

SanityCheck.py is the script for checking cross-correlation of Flexlab
runs. It works for both TCP and UDP transfers. I also changed
auto-pelab.ns and added a "-t" option to start-experiment
and stop-experiment to enable these sanity checks.

Note: I haven't figured out how to kill sudo tcpdump sessions
on PlanetLab with program agents - so, for now they have to be
killed manually after a stop-experiment. Will change this after
talking to Mike.

The cross-correlation code works correctly - I may need to tweak it
a bit in the near future for averaging times.
Also, it puts too much load on Ops and (i think) takes too much time.
I will change it so that all the correlation calculations are done on
the experimental nodes.

file that does not exist.

interfaces.

have only really been 'documented' in the code.

This file is for two purposes: First, so that I can hand it to people
we are giving top and ptop files to. Second, as I build up the new
XML-based top and ptop files, I need to have the 'features' of the old
file formats documented.

interfaces to be run at 100Mb without a delay node.

elvin_gateway with the daemon_wrapper

processing the node_history table, but that is *way* too slow to do on
the fly (say, from the web interface) cause of the number of records,
so the summary info is stored in the new node_utilization table. I
generate the summary info as new entries are added to node_history (in
SetNodeHistory) but if that becomes too messy, we can just as easily
shift to processing the table on a nightly basis.

Note that I added a new "inception" date field to the nodes table,
which will get set on new nodes, but for existing nodes I have to
derive it from the first entry in the node_history table, or else the
numbers will not make sense.