https://www.emulab.net/showosid_list.php3?creator=stoller
	https://www.emulab.net/showimageid_list.php3?creator=stoller

A quickie; it can be worked in better if we want.

not ever need to create a OSID directly, so do not give them the link.
Will need a mechanism to allow this later for Eric and others with a
clue. Also add pointer to customos section of the tutorial at the top
of the page.

the newimageid_explain front page, since I had actually moved most of
that text into the tutorial a couple of months ago. I moved the rest
of the text over, and changed the links to point to the short form.
Added a link at the top of the short form pointing to the tutorial
section, and for admin types, a link to the long form.

there are no osid/images to list.

The big one.

New look;
most of the changes are in menu.php3.

A lot of the changes in other files are s/<TD>/<TH>/
for table headers.

Also closed some tags, tweaked some table styles, etc..

No actual functionality should have changed.

Will be installing soon...

call 'em tuits (okay, I have no idea what a tuit is).

tb-set-node-os and another explanation in the OS descriptor list
page. Yes, its clear that the distinction between imageIDs and OSIDs
is just plain confusing.

Update pages appropriately. Also cleanup up a few more sub menus.

supporting autocreating and autoloading images. The imageid form now
sports a field to specify a nodeid to create the image from; If set,
the backend create_image script is invoked. Thats the easy part.
Slightly harder is autoloading images based on the osid specified in
the NS file. To support this, I have added a new DB table called
osidtoimageid, which holds the mapping from osid/pctype to imageid.
When users create images, they must specify what node types that image
is good for. Obviously, the mappings have to be unique or it would be
impossible to figure it out! Anyway, once that image mapping is
in place and the image created, the user can specify that ID in the NS
file. I've changed os_setup to to look for IDs that are not loaded,
and to try and find one in the osidtoimageid. If found, it invokes
os_load. To keep things running in parallel as much as possible,
os_setup issues all the loads/reboots (could be more than a single set
of loads is multiple IDs are in the NS file) at once, and waits for
all the children to exit. I've hacked up os_load a bit to try and be
more robust in the face of PXE failures, which still happen and are
rather troublsesome. Need an event system!

Contained in this revision are unrelated changed to make the OS and
Image IDs per-project unique instead of globally unique, since thats a
pain for the users. This turns out to be very messy, since underneath
we do not want to pass around pid/ID in all the various places its
used. Rather, I create a globally unique name and extened the OS and
Image tables to include pid/name/ID. The user selects pid/name, and I
create the globally unique ID. For the most part this is invisible
throughout the system, except where we interface with the user, say in
the web pages; the user should see his chosen name where possible, and
the should invoke scripts (os_load, create_image, etc) using his/her
name not the internal ID. Also, in the front end the NS file should
use the user name not the ID. All in all, this accounted for a number
of annoying changes and some special cases that are unavoidable.

replaced by the "images" table. New os_info table is added. New web
pages to add and delete OSIDs to/from the os_info table, for use in
the NS file. tb-create-os is gone. handle_os no longer operates on the
tbcmds file, and no longer writes anything into the ir file. Moved the
setting up of os state (nodes table) from os_setup to handle_os, where
it should be. os_load and sched_reload now take a single argument, the
name of the imageid from the images table.