Somehow, the last time I ran this, it didn't pick up the default
for the ARISTA_SWITCH_XMLRPCPORT variable.

Weibin Sun authored Aug 10, 2012 and Robert Ricci committed Aug 13, 2012

Add fake commands for port-control to avoid errors since our Arista
  switch just support one mode.
Just double checked that _setAllowedVlansOnTrunkedPort does add or remove
  VLANs rather than setting them as the only ones.

Weibin Sun authored Jul 26, 2012 and Robert Ricci committed Aug 13, 2012

Debug cmd option added for snmpit agent, and also more pretty log output; Enable port after adding it into VLAN.

Weibin Sun authored Jul 26, 2012 and Robert Ricci committed Aug 13, 2012

Commit for Autoconf var settings, not ready for installation, need run autoconf on boss with Autoconf 2.62

Weibin Sun authored Jul 25, 2012 and Robert Ricci committed Aug 13, 2012

Simple VLAN operations used on web should work now. But for installation, need Autoconfig variable settings, and also figure out why XMLRPC client on boss can not connect to switch server but client on switch can.

Weibin Sun authored Jul 19, 2012 and Robert Ricci committed Aug 13, 2012

Add configure variables for Arista agent port and binding address; Snmpit_arista functions implementation almost half way done; Trunking left untouched, need a guide.

Weibin Sun authored Jul 12, 2012 and Robert Ricci committed Aug 13, 2012

Put workable(on switch's Python shell) code into agent, those include VLANcreating/deleting, port-VLAN (un)assigning, port (un)tagging.

Weibin Sun authored Jul 05, 2012 and Robert Ricci committed Aug 13, 2012

Arista module code skeleton added. Some getters can already work, I guess. The switch side deamon also added, no real code yet.

The basic problem is that when snmpit looks to see what ports it
should trunk (or untrunk) the equation is more complicated then it
used to be.

Case 1: In the old days, before shared nodes and shared lans, a node
and its interfaces were always one-to-one with an experiment. So the
set of trunks was easily derivable from the reserved table joined with
the interfaces table.

Case 2: But when we added shared nodes (with vlan encap of course),
the set of trunk ports is no longer associated with the experiments
using those ports, but only with the underlying experiment. That is we
do not mess with the trunking when swapping experiments on shared
nodes, we only want to add and subtract vlans to those trunked
ports. So, I added a check against the reserved table. Easy. The ports
are trunked when the underlying "shared nodes" experiment is swapped
in, and untrunked when it is swapped out.

Case 3: Then we added shared vlans. Well this is almost the exact
opposite case. The ports belong to nodes in other experiments, but now
we *do* want to consider them when turning trunking on and off. The
underlying experiment that owns the lan (emulab-ops,openflow-vlans)
does not own any of the ports, but we do want to enable/disable the
trunking as ports come and go.

Case 4: Last but certainly not least, is a potential bad interaction
between these #2 and #3! The instageni-connect port is a member of the
1750 shared vlan (and thus trunking is enabled when the openflow lan
is created or modified). But that same port is also used in the second
case above when stitching to the rack; The instageni-connect node is a
shared node, and we allocate fake VMs on it that serve simply as a
place to associate the vlans that use that port; we just want to add
and subtract vlans to the port. ÊThe gist of this is that if someone
were to remove the port from the shared 1750 vlan, its trunk would get
turned off, and all of the stitched vlans would stop working.

This bug fix deals with the addition of #3, but I do not have anything
for #4.  But I can commit this fix with the understanding that
#4 is a real problem that has to be dealt with.

Due to improper plumbing of the NOSHAREDFS attribute, all nodes were trying
to create the shared logging dir. The race was between checking for the
existence of the directory and trying to create it.

The size of the block header differs depending on the version of the image.
sizeof(blockhdr_t) gives the size of the current version of the header when
the binary was built (V4 currently). This only mattered in two places:

In imagezip, it would have prevented us from creating a backward compatible
V1 image. Probably nobody has done this in 10 years.

In imageunzip, it could prevent relocations from being processed. This only
affected recent builds (V4 format) when attempting to unzip an older
single-partition FreeBSD image (FBSD5 or before). This is unlikely to occur
outside of Utah and only very rarely here.

Otherwise, pubsubd won't start til after the testbed startup. Since
checknodes_daemon wants to send an event, it will hang forever if pubsubd
is not running.