GitLab

a huge amount of work, but really needs someone to test drive it.

mode, the User Profile menu has a new "Su as User" option that flips
you to the target user. You are effectively logged out and logged back
in as the target.

No going back; you have to log out to return to your former self. That
would be too much work for something that is a rare event.

they are available to the program agent when it starts. I copy the values
at swapin and at each experiment run start. However, the program agent
does not currently have a way to reload the environment while an experiment
is swapped in, short of restarting the agent. Need to figure that out
next, so at present, you only then the initial values at swapin.

In this case, lets watch for a change to the current PID (process id)
and force a reconnect.

to the Cisco code too, but I want to do more investigation of them
before committing.

More reliability fixes/enhancements.  Hopefully this will catch the remaining
problems I've seen happen.

not all nodes have to be on the same switch.

Fixup the plabconfig command in tmcd to return immediately if the calling node
is not a plab vserver (sliver).

* Rework metadata to be somewhat more general so that they can be used for
  things like parameter descriptions.

* My own little part of javascript hell ... add a highlight around the
  "current" template in the template graph. Sheesh!

* Add more tooltips (using the tooltip library). When you mouseover the
  metadata or descriptions, the formatted text is shown in a tooltip,
  which is handy when the valus is truncated cause its too long for the
  tables.

that happens automatically now.

(%%nodetype) than the nodes it served, we would generate illegal dhcpd.conf
syntax.

much "fun" as the Perl conversion, but nothing about PHP is as much
fun as it is in perl.

until I figure out the rest of deleted users wrt stats. I was working on
this at some point, and some crisis must have intervened ...

was using MAX(exptidx) from the experiments table. Instead, lets use
a new one each time.

This avoids a problem in the new template code I need to fix at some
point.

tb-set-node-plab-role $plc plc

to make it the PLC node.  Then any number of other nodes are declared as:

tb-set-node-plab-role $plab1 node

to make them inner plab nodes.  Unlike elabinelab, there is no magic
"tb-plab-in-elab" command which implies the topology, you put all the
plab nodes in a LAN or whatever yourself.  This may or may not be a good idea.

Anyway, these NS commands set DB state in virt_nodes and reserved much like
elabinelab.  During swapin, the dhcpd.conf file is rewritten so that
inner plab nodes have their "filename" set to "pxelinux.0" and their
"next-server" set to the designated PLC node.  The PLC node will then be
loaded/booted before anything is done to the inner-plab nodes.  After
it comes up, the inner plab nodes are rebooted and declared as up.
There is a new tmcd command "eplabconfig" (suggestions for a new name
welcom!), which returns info like:

    NAME=plc ROLE=plc IP=155.98.36.3 MAC=00d0b713f57d
    NAME=plab1 ROLE=node IP=155.98.36.10 MAC=0002b3877a4f
    NAME=plab2 ROLE=node IP=155.98.36.34 MAC=00d0b7141057

to just the PLC node (returns nothing to any other node).

The implications of this setup are:

 * The PLC node must act as a TFTP server as we have discussed in the past.
   The TMCC info above is hopefully enough to configure pxelinux, if not
   we can change it.

 * The PLC node is responsible for loading the disks of inner plab nodes.
   This is implied by the setup, where we change the dhcpd.conf file before
   doing anything to the inner nodes.  Thus, once the inner nodes are
   rebooted, they will be talking pxelinux with PLC, and not to boss.
   This step is dubious, as we could no doubt load the disks faster than
   whatever plab uses can.  But it simplified the setup (and is more
   realistic!).  The alternative, which is something that might be useful
   anyway, is to introduce a "state" after which nodes have been reloaded
   but before they are rebooted.  With that, we can reload the plab nodes
   and then change the dhcpd.conf file so when they reboot they start
   talking to the PLC.

an alternate pxe_boot_path: when bootinfo is invoked for a node for which
pxe_boot_path is non-NULL and doesn't look like the RE: '.*pxeboot.*'
then we tell the node to reboot so that it will come back up in the
proper PXE boot program.

"object" and this was a good opportunity to see if they are useful and
easy enough to use. Yep they are; the code is much cleaner with many
fewer utility functions to get at stuff. I recommend this approach
from now on.

The problem is the php side, which ends up duplicating some stuff, but
in the old style. This is not so bad for the template code since I
have made it a point not to do anything but display functions in php;
all modifications are handled in the backend.

dhcpd_makeconf.in: leave the hostname setting for plabinelab nodes
nfree.in: make sure that if we free a plabinelab or elabinelab node,
          that we reset the dhcpd.conf file

* setup some fields that parallel the
  elab-in-elab ones, for modifying the dhcpd.conf file.

* tb-set-node-plab-role to set a node as either 'plc' or 'node'
  used to set the DB role field above

reserved name clashes.

show template page, to some primitive zoom code in the backend. It will
do for now.