troubleshooting entry.

table to the location_info table.

new_nodes table. Thought it would be easy, but ended up doing more
damage then I expected; oh well. New nodes show up in "gold" color
(not listed in the legend).

I added a link from the newnode_edit page. Rob will need to arrange
for a location_info entry to be created when a new node is made live
(but only if building/floor are not null).

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.

that I added to the DB. See revision 1.251 of sql/database-create.sql.
I have removed all of the hardwired names of buildings, images, files,
etc. I have also added MEB floors 1 and 2, but they do not show up on
the status page unlesss there are actually nodes assigned to them.
When you go to set a node location, you do see the little thumbs of
all existing buildings/floors, so you can add nodes to floors that do
not currently have any.

Still needs some work to cleanly display multiple buildings, but thats
for another day.

sql/database-create.sql. The old ips slot of virt_nodes is left in
place while we transition over.

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.

* Redo all the MEB .png files, removing the existing titles from the
  images, and cropping down the images to the actual floors. Redid the
  thumbnail files at the same time. Note that the existing location_info
  entries need to be updated, which I will do.

* Rework portions of floormap.in in preparation for using the DB to
  describe the image files (still hardwired into the floormap).

* Draw a title in each image using a truetype font, based on what will
  eventually come out of the DB, plus a floor tag.

* Add option (-t) to not draw any titles; just naked images.

disambiguate from boost's random() function. But, for some reason,
with 3.x, random() doesn't live in the std:: namespace. Macro-ize it.

to virt_lans table only; See revision 1.249 of sql/database-create.txt
for all the gory details. This includes the awful queries in doifconfig
that appeared to be O(N*N*N)!

Shashi, my changes to hostnames might have broken NSE specfic stuff; I was
not able to understand your comment about it, so maybe you better check to
make sure I didn't mess something up. Eventually, we won't be returning
hostnames from tmcd, but it should work during the transition phase.

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

a physical link with enough bandwidth for the virtual link. This fixes
some problems with physical nodes that have multiple links of
different speeds.

frisbee won't suck up for buffering).  Also check the kernel limit for
maximum datasize and take that into account.  (Related to this: I have
changed the frisbee MFS loader.conf file to set kern.maxdsiz=2000000000)

  SFS.

* Do not send SSH pubkeys to local nodes; the data is never used on
  local nodes, but along with SFS keys, comprises about 85% of the
  data we send back in the accounts request.

admin people allowed. Comment from script:

# * Initially we come in with just a nodeid. Display a page of little maps
#   and titles the user must select (a floor in a building) from. User clicks.
# * Next time through we have a building and floor defined in addition to the
#   the nodeid. We put up that big image with the current nodes on that floor.
#   We use the external floormap program to generate that image, but without
#   an imagemap. Instead, we use a form with an input type=image, which acts
#   as a big submit button; when the user clicks in the image, the browser
#   submits the form, but with the x,y coords added as form arguments.
# * We get all of the above arguments on the final click, including x,y. Verify
#   all the aguments, and then do the insert.
# * If user goes to reset the node location, form includes an additional submit
#   button that says to use the old coords. This allows us to change the contact
#   info for a node without actually changing the location.

Caveats:

* We do not describe buildings in the DB, and so we are currently hardwired
  to MEB for the building, and the images for each floor are still
  hardwired in the external script (vis/floormap.in) that creates the
  image. Needs to be dealt with before we can export this stuff.

* There is no way web interface to delete a location entry. That should be
  easy to deal with when needed, but in the meantime:

	delete from location_info where node_id='pcXXX'

* All nodes get a "Set Location Entry" on the shownode page menu; I leave
  it to admin people to not set the location for a non-wireless node; will
  fix later as needed.

* Coordinates are all in pixels. As Russ points out, this is (way) less
  then ideal, but certainly simple.

the fly, or use heigh/width specs in the img tag, but I hate how the
browser scales things. Short term solution; obviously does not scale
to more then a few floor images.

otherwise the file is created as that user, and is then difficult to
remove in floormap_aux.php3 after it is dished out. There is no reason
to run the external script as the user; all it does is build an image.

cached version.

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

we can use it for a partition number

of my really icky code to start different kinds of servers; basically
you can set the number of servers of each kind, and if a server of
that type exits, another one of the same type is started. The code is
a little easier to follow then it was before, but still quite yucky.

So whats the "right" way? The problem is that if multiple children are
selecting on a set of fd's and an fd comes ready, all of the children
are woken up. This is called a "select storm" since they all wake up,
try to read from the same fd, and all but one go right back to sleep.
Lots of overhead, and programs like apache go to great lengths to
avoid it. Takes a lot code, lots of bookkeeping, lots of goo that is
hard to understand 6 months later. Not worth it for tmcd, at least not
yet. If we start creating many 1000s node experiments, that could
change in a hurry.

format instead of plain old well formed XML. Note this change does not
affect the parser in any way; the parser continues to spit out its own
brand of XML, and xmlconvert treats that special when it reads it.

The XML I spit out now is better formed and makes more sense when you
look at it. It also helps that its much faster to generate, and the
resulting output is much smaller. For example:

	time /usr/testbed/libexec/xmlconvert testbed jail-2440
	real    2m54.229s
	user    1m7.492s
	sys     1m15.927s

	time /usr/testbed/devel/stoller/libexec/xmlconvert testbed jail-2440
	real    0m14.738s
	user    0m5.755s
	sys     0m5.156s

	/tmp/bar*.xml
	-rw-rw-r--  1 stoller  wheel  15595161 Jun  4 11:16 /tmp/rpc.xml
	-rw-rw-r--  1 stoller  wheel   5285690 Jun  4 11:17 /tmp/plain.xml

Thats for a big experiment. For a small experiment:

	time /usr/testbed/libexec/xmlconvert testbed jail-416
	real    0m9.346s
	user    0m5.083s
	sys     0m2.675s

	time /usr/testbed/devel/stoller/libexec/xmlconvert testbed jail-416
	real    0m2.751s
	user    0m1.377s
	sys     0m1.183s

	ll /tmp/bar*.xml
	-rw-rw-r--  1 stoller  wheel  3135518 Jun  4 11:19 /tmp/rpc.xml
	-rw-rw-r--  1 stoller  wheel  1015745 Jun  4 11:19 /tmp/plain.xml

As you can see, the RPC code is rather non-linear in its performance!

Since this affects Tim and netlab-client, I have added an alternate
XMLRPC routine called virtual_topology_xml() that returns the new format,
since Tim will need to transition to this new format (parsing it into a
Java data structure). The old format is left in the RPC server until that
is done.

wireless.

Parse the ptop file to get information like colocation factors, CPU
speeds, trivial bandwidth, and the like, instead of hard coding them.

Keep features and trivial bandwidth by type (ie. pcvm, pcvm850),
instead of making them the same for all types. This should make
much better conglomeration choices.