happy.

       that an experiment prefers to use modelnet for traffic shaping.
       At some future time maybe we can mix modelnet with delay nodes,
       but please do not hold your breath waiting.

	alter table experiments add usemodelnet tinyint(1) NOT NULL \
		default '0' after useprepass;

       Add modelnet_cores and modelnet_edges variables to hold user
       tunable number of physical core nodes and edge nodes to throw
       at a virtual topology.

	alter table experiments add modelnet_cores tinyint(4) unsigned \
		NOT NULL default '0' after usemodelnet;
        alter table experiments add modelnet_edges tinyint(4) unsigned \
		NOT NULL default '0' after modelnet_cores;

       Add ismodelnet and isphantom slots to node_types table. ismodelnet
       is set for modelnet nodes (which are also going to be isvirt).  Add
       isphantom to mark nodes that do no get underlying physical nodes;
       there will be an entry in the reserved table but no entries in the
       nodes table. Initially, modelnet virtual nodes will all be phantoms.
       Will possibly change later.

	alter table node_types add ismodelnet tinyint(1) NOT NULL \
		default '0' after isvirtnode;
	alter table node_types add isphantom tinyint(1) NOT NULL \
		default '0' after ismodelnet;

       Not sure that isphantom is going to work cause of the number of
       queries that join reserved with the nodes table. I might end up
       making nodes dynamic instead, creating and detroying them on the
       fly. I would prefer that isphantom works, but I am willing to live
       with isdynamic since we can use that for all of our virtual nodes.

	alter table node_types add isdynamic tinyint(1) NOT NULL \
		default '0' after isphantom;

off linktest async via the web interface.

even if the disk is up to date.

table - this will allow us to place them on the map while they are still
in limbo.

 ALTER TABLE new_nodes ADD COLUMN (floor varchar(32) default NULL,
    building varchar(32) default NULL,
    loc_x int(10) unsigned NOT NULL default '0',
    loc_y int(10) unsigned NOT NULL default '0',
    contact tinytext,
    phone tinytext,
    room varchar(32) default NULL);

number in database-migrate.

This is rather primitive still; We just need a place to define
buildings and floors in buildings, so that we do not hardwire them
into the code. This can get arbitrarily complicated, but not until we
need it.

	CREATE TABLE buildings (
	  building varchar(32) NOT NULL default '',
	  image_path tinytext,
	  title tinytext NOT NULL,
	  PRIMARY KEY  (building)
	) TYPE=MyISAM;

The image_path is optional for buildings. The title is a string to
print along with the images (Merril Engineering Building).

	CREATE TABLE floorimages (
	  building varchar(32) NOT NULL default '',
	  floor varchar(32) NOT NULL default '',
	  image_path tinytext,
	  thumb_path tinytext,
	  x1 int(6) NOT NULL default '0',
	  y1 int(6) NOT NULL default '0',
	  x2 int(6) NOT NULL default '0',
	  y2 int(6) NOT NULL default '0',
	  PRIMARY KEY  (building, floor)
	) TYPE=MyISAM;

The image_path is not optional; it is either an absolute path or a
filename in $TB/www. The thumb_path is for a tiny view of it. Floor is
something like 1, 2, 3 but could also be basement, lobby, penthouse,
etc. The x,y coordinates are intended to be bounding box coords of the
"interesting" part of the image so that it is easier to scale specific
entries from the location_info table. But, not really sure about this
yet; needs more thought and some investigation about appropriate ways
to store coordinate values like this.

virt_lans and virt_nodes. The intent is to migrate away from
the convention we use in virt_nodes:ips and virt_lans:member
to a more acceptable representation (one that does not rely
on textual conventions like space separated lists of colon
seperated entities. Instead:

	virt_nodes
		vname:	nodeA
        virt_lans
		vname:  link0
		vport:  0
		ip:     1.1.1.2

		vname:  link1
		vport:  1
		ip:     1.1.2.2

	alter table virt_lans add vnode varchar(32) NOT NULL default '' \
		after vname;
	alter table virt_lans add vport tinyint(3) NOT NULL default '0' \
		after vnode;
        alter table virt_lans add ip varchar(15) NOT NULL default '' \
		after vport;

Then run this script to update these new fields from the
existing ips,member slots. This must be run after installing
the parser changes, or you can just run it again.

	./ipmember.pl

This is a transitional phase; the old slots will be left in place
until they are no longer used, at which time we will also add a
unique key to the table (pid,eid,vname,vnode,vport). assign_wrapper
will be the hardest to change, but other scripts should be easy.

Whats vport about? Rather then rely on IP addresses to form a
unique key, we use vport (a small integer) so that we can delay the
IP assignment until later (after initial DB insertion).

passing this to the newnode client, web page, and viewing and
editing it.

on and off the assign prepass on a per-experiment basis.

No parser interface yet - for use only with manual tweaking for now.

'loadinfo' request.

estimated bandwidth that will be used on the link/LAN. This can then
be passed to assign, to do less conservative bandwidth allocation.

see (or remember) any reason for this slot to be 20 chars, when the
name of every other vname slot is 32. I looked in the event scheduler
and there do not appear to be any problems there with bumping it. Note
that I choose 64 cause we tend to construct agent names that might be
longer then 32 since they are based on real vnames (lan0, node0, etc).

arbitrary interface settings associated with the virtual part of the
topology.

settings to the nodes when they configure their interfaces. Added primarily
for wireless interface support.

not to run linktest.

an "is_accesspoint" boolean to virt_lans. The former defaults to
"ethernet" but can be set to anything (80211a, 80211b, etc) in the NS
file. The is_accesspoint is temporary, and simply allows you to set
which node is the accesspoint in the NS file. This slot will probably
move to another table at some point.

Added interface_capabilities table, which is intended to list the
capabilities and the default values, for interfaces listed in the
interface_types table. This allows a more flexible description of
interfaces, expecially wireless devices. Initially, I have seeded the
table with just the default protocol (ethernet) and the speed. For
example, the fxp:

	fxp              | protocols         | ethernet |
	fxp              | ethernet_defspeed | 100000   |

As you can see, protocols is plural, and is intended to be a comma
separated list. So, for the atheros wireless card:

	ath              | protocols         | 80211a,80211b,80211g |
	ath              | 80211a_defspeed   | 54000                |
	ath              | 80211b_defspeed   | 11000                |
	ath              | 80211g_defspeed   | 54000                |

I gave up on using the entire row as a primary key; this is just too
painful from perl/php/python where hashes are the most popular data
structure, and duplicate columns get overwritten.

are considered part of the emulab service.  I've set it for 'utah_elab_svc'.

* Added 'leaseend' column to plab_slices table.

instead of only 10 characters.

module-specific data.  Also, fixed numbering skew that started at v 1.223
(someone decremented the version by 100).

chars) to text (65K chars) to avoid too-short problems with program
agent command lines. Note that the maximum size allowed by table_regex
checking will be set to 1024 for now.

we're adding a small number of nodes by hand, we can set these.

for Jon's ipassign stuff.

is_info table.

vnodes (via their pnode).

paper effort. Note, not an osid, but an osname like we specify for a
virt_node. Lookup rules are the same; first check the current project
for a match, and then check emulab-ops.

from one pnode to another during a swapmod.

into table_regex.

vnode weights (like CPU) and do a swapmod. This is a hammer but will do
for now.