GitLab

active at a time. This avoids the situation where a person enters many
batches, and they get scheduled all at once, sucking up every node in
the testbed.

trying to start a new one (as in replay).

MODIFY command.

this was the only script still using the old log location.

removed mention of them from the boss setup documentation.

Note that this means we no longer tell people to /var/log/testbed to
/usr/testbed/log, since the former is deprecated.

variables to be renamed from within a subroutine:

	proc create_testnet {} {
		set s1 [$ns node]
 	}

Chris' redefined set did not allow this. This is further complicated
by the fact that its difficult to tell whats a global variable. You
can declare a variable global, but until its set for the first time,
the TCL info function will not tell you its a global. We do not want
to rename locals of course, since that would make no sense to do.
Anyway, Brian contributed the code to fix the new set function, and I
looked at it and did my best to understand it (I kinda do), but no way
I can be sure! I ran it through the test suite and spot checked the DB
state. Seems to work okay.

Also fixed bug where changing packet size would change an explicitly
specified packet rate because we only tracked the packet interval.  E.g.:
	set packetSize_=100
	set rate_=100
would result in a packet rate of 100Kbps, but then doing:
	set packetSize_=1000
would result in a packet rate of 1000Kbps even though the rate was not
explicitly changed.  Now we actually keep track of whether the rate was
explicitly set and, if so, change the interval to maintain the rate.

(on the physical node the tmcd request is coming from) look for a
VNODE= tag in the request (similar in operation to VERSION=). If there
is a vnode tag, then check for that mapping (in the nodes table). The
vnode must map to the physical node making the request (in iptonodeid()).
If so, replace the nodeid with the vnodeid for the remainder of the
session. Currently no permission checking, so a vnode could ask for
another vnode's account data (on the same physical node of course). At
some point we need to either generate per vnode certs (perhaps on the
fly) or just cons of a secret key and pass it over. Not going to worry
about it for now, since the only people who will be allowed to
allocate virtual nodes are trusted anyway.

event.

source, which is something of a problem. The ugly solution right now
is to send reset events to both the source and sink (sink first I
would think) if you need both sides to get it.

	$ns at 1 "$null0 reset"
	$ns at 1 "$cbr0 reset"

Another option might be to internally create the second event for
reset ...

interupt the current next up event cause Ian's code just grabbed it
off the queue and went into select. I converted this code to use a
condition variable and a timed wait. If a new event comes in, signal
the waiter who can recheck to see of the head of the queue has
changed. Seems to work, but not well tested. This bug reported by Rob!

iface_counters.

(found with 'mysql -d tbdb' as suggested by Rob.)

virtualization won't cure someday.

and virt_lans to determine which links/lans need to be dropped out of
the list given to assign (.top file). Basically, if a simple link has
virtual node in it, get rid of the link (both sides). If a lan has a
virtual node in it, then get rid of just that member of the lan (the
other regular members need to be allocated as usual). There is a minor
problem of a lan with just one physical member left after dropping the
virtual members; not sure what to do about that so I punted on it for
now.

Note that I *do* send the virt_nodes into assign for allocation as
unconnected nodes. Its up to the user to create the routes properly,
although maybe we have to do that automatically?

nodes.

the underlying physnode instead. The virtual nodes are currently
static, but will eventually by dynamic, and so it makes no sense to
have entries in base named map (like there is for pcXXX).

time.

sure that a virtual node free does not result in an entry in the
last_reservations table, since its a meaningless concept, and we do
not want the reload daemon to see it as a node that needs to be
reloaded.

node_types table (isvirtnode).

DB table. If a nodetype turns up in this table, its retstricted,
otherwise its a normal unrestricted node.

node types, or all nodes.

various places (like the node list).

addition to to being free, the underlying physnode has to either be
free, or not in the hwdown group. Either way, the the underlying
physnode has to be "up", as determined by the autostatus stuff; this
will prevent us from allocating a dead virtual node to an experiment.
The hwdown stuff is especially hacky; we need a better way of
determining what nodes are available to be multiplxed. This will do for
the (very) short term.

allowed to allocate a node type. An entry in this table means the type
is restricted; no entries means the type is unrestricted.

Add "isvirtnode" slot to node_types table so that we can put in
entries like pcvron, pcvroninet2, etc. Various parts of the testbed
software will check this flag.

Add phys_nodeid slot to nodes table, which maps a virtnode to its
physical nodes (vron23 maps to ron3). Set phys_nodeid=node_id for
normal testbed nodes.

Change type of priority in the nodes table to a plain int (from
smallint) since I added a bunch of nodes and spread the priority
numbers out pretty far.

be links.