GitLab

This is useful for the new r430s where the control net location varies
depending on how many 1Gb experimental interfaces the node has.

shellinaboxd daemon and/or the wrapper is doing something strange that
makes apache unhappy.

all the time, so bail on that and fallback to reporting errors solely
though the spew log(s).

gone at the remote cluster.

* A new Start Linktest button is in the bottom right of the topology tab.

* When started, we create a new tab to display the linktest output
  (currently the unmodified output from Classic emulab linktest). The state
  of the experiment is change to linktest to prevent further action on the
  experiment, except of course for stop linktest.

* When linktest is running, there is a Stop Linktest button in the upper
  collapse panel. This will stop linktest in its tracks, but the tabs
  remain. When you kill a linktest tab while linktest is running, linktest
  continues running, you have to use the Stop button.

* I have added a small help document to the templates directory that the
  user is shown when they click on the ? mark in the linktest modal.
  Written in markdown format, it is a culling of text from the Emulab wiki
  linktest page.

Caveats:

* Because of polling, there is a short (5-15 seconds) delay before the
  experiment is returned to the ready state. Not much to do about this in a
  polling world. Wouldn't callbacks be nice?

* Linktest can be used on a multisite topology, although cross site links
  cannot be tested at this point. Links/Lans that are contained entirely to
  one site or the other are testable though. We build a new tab for each
  site to spew the linktest output.

* Three actions are exported; start, stop, and status. The last is cause we
  have to poll to determine when linktest has actually finished or stopped.
  I hate all this polling.

* For start, linktest can be performed synchronously, which is fine on a
  small experiment, but in general you want to use the async option and
  check back later. When using async, we return the spewlog URL to the
  caller so that linktest can be monitored.

* A couple of minor changes to linktest itself for using a spew log.

* Some simple test rspecs and a linktest.py driver.

definitions.

good change in general.

page can use the Shell button to log in as themselves.

invoke emulab-enet so that the iptables forwarding rules are added.

and treat those as fatal errors instead of user errors.

Portal, what clusters are usable by each portal, ditto datasets. Remove
all hardwired cluster urns and urls.

Before connecting to a controller, an OF-enabled VLAN should not
pass any traffic (to avoid exotic inter-site L2 loops).

Also update my mothership defs file.

Will this trivial fix really fix "geni-get manifest"?  If so, I
should have done it long ago!

Image->AccessCheck() to see if the user is allowed to use the image
via the image_permissions table.

end node shaping, this change does not affect bridge shaping).

First off, duplex links are not affected. I expect that duplex links are
the majority usage anyway. What I did change is the way we insert the
virt_lans table entries to be exactly like what the NS file does. This will
not affect the delays, but it makes linktest happier (see below) when
testing duplex links.

For lans (more then two nodes) we were always broken. Consider what we have
now: 

 <link client_id="mylan">
   <interface_ref client_id="node1"/>
   <interface_ref client_id="node2"/>
   <interface_ref client_id="node3"/>
   <property source_id="node1" dest_id="node2"
           capacity="50000" latency="15"/>
   <property source_id="node1" dest_id="node3"
           capacity="50000" latency="15"/>
   <property source_id="node2" dest_id="node1"
           capacity="50000" latency="15"/>
   <property source_id="node3" dest_id="node1"
           capacity="50000" latency="15"/>
   <property source_id="node2" dest_id="node3"
           capacity="50000" latency="15"/>
   <property source_id="node3" dest_id="node2"
           capacity="50000" latency="15"/>
</link>

This cannot actually be supported by the virtual topology in the database.

In Emulab the virt_lans table allows you to specify for each node, the
bw/latency/loss going "from the lan to the node" and rbw/rlatency/rloss
"going from the node to the lan". Think of the "lan" as a fake node in the
center of a star.

                        N1
		   bw   |  | rbw
		delay   |  | rdelay
		 loss   |  | rloss
			|  |
           N2  ------- LAN ------- N3
               -------     -------

So one of the lines is "from the LAN node to N1" and the other line is
"from N1 to the LAN node". Ditto for N2 and N3.

In other words, you cannot actually specify a different set of parameters
from a node to each of the other nodes, as the pairwise properties above
imply.  A translation of what we actually do is more like this:

   <property source_id="node1" dest_id="mylan"
           capacity="50000" latency="15"/>
   <property source_id="mylan" dest_id="node1"
           capacity="50000" latency="15"/>
   <property source_id="node2" dest_id="mylan"
           capacity="50000" latency="15"/>
   <property source_id="mylan" dest_id="node2"
           capacity="50000" latency="15"/>
   <property source_id="node3" dest_id="mylan"
           capacity="50000" latency="15"/>
   <property source_id="mylan" dest_id="node3"
           capacity="50000" latency="15"/>

Which allows you to set the simplex parameters for each node TO/FROM THE
LAN.  Each node can a bw/latency/loss to the LAN and a different
bw/latency/loss from the LAN. This is supported in the classic NS file
syntax, although this is not what a simple "make-lan" does; there is
currently no syntax to support that in Geni; a NS file make-lan statement
that sets the delay to 15 means that the delay is 7.5 to the LAN and 7.5
from the LAN, so the delay between two nodes is 15. In the NS syntax, once
you start messing with per-node shaping settings, you have to do it like
above. So in the above example, the delay between any two nodes is 30ms.

But the above is a little too confusing, so rather then doing simplex
parameters I implemented duplex parameters:

   <property source_id="node1" dest_id="mylan"
           capacity="50000" latency="15"/>
   <property source_id="node2" dest_id="mylan"
           capacity="50000" latency="15"/>
   <property source_id="node3" dest_id="mylan"
           capacity="50000" latency="15"/>

If someday we think that people need simplex parameters for each node in a
lan, we can add that.

As for linktest ... I added the linktest agent to Geni experiments, and I
set the sync_server default so that linktest can actually run. In another
commit I will push up the change that export linktest from the CM
interface, as well as portal changes to use it.

same cluster.

portal.

Note that TBMAINSITE site refers to the MotherShip, not a specific
version of the web site.