GitLab

figured out.

physical or virtual, as indicated by the isvirtnode flag.

Update database-create.sql from last commit.

accounts on slivers.

Users package to create them. Nonlocal users will be returned to nodes
that are part of a federated experiment, and keeping them separate from
local users seems like the safest thing to do.

Also a few other minor changes.

Note that I did not change the plab code; needs to be done.

revocation, multiple encrypted certs, passwords for keys, etc.

to the corresponding object at that PLC.

off plc,slice,nodegroup,node_id tuples, as appropriate).  Also add
support for sucking down plab nodegroups.

widearea_nodeinfo in support of widearea nodes that need their networks
to be configured statically.  Also the plab sync support for this, and a
sync bugfix.

easier.

Also add a daily_stats table that will record, you guessed it, the
daily stats, which will be a mucg faster wayt to see what is going on
and even generate some graphs.

tables.

Remove the tunnels table since that stuff is now in the
lan_member_attributes table.

Add node_id to the lan_members table. While its nice having that as an
attribute, it makes joins more difficult and slower.

(Rob,Mike,Jay) have overflowed an unsigned int.

lan_member_attributes, and ifaces. Making the world safe for protogenis.

hoops to find the virt_lan and vlan that a vinterface is associated with,
lets just store a backpointer. It also makes my next round of changes for
lans easier to transition to.

  tb-fix-interface $node $link "iface"

instead of paths. There is a script called from database-migrate that
converts paths to logfile (db) objects.

sandbox, and that I did. It falls back to the older archive when
the template is older then CVS repos.

But along the way I got annoyed with the fact that template instantiation
does not provide a logfile to the web interface. The reason is that
the current logfile stuff is very experiment centric; there has to be an
experiment and an attached logfile. An instance does not have an experiment
until really late in the game so the code was just not bothering.

Anyway, I've started to generalize the logfile stuff with a new table
and the approach that a logfile is named by a random key, and if you
know the key you can look at the logfile in the web (since without an
experiment it is hard to do permission checks unless we make logfiles
uid/gid owned, and I did not want to do that.

Also commit the DB changes.

widearea reloading support.

* New slot in the images table to store an access key which remote
  sites must provide in order to download an image (via https).

* tmcd returns a different kind of ADDRESS field from doloadinfo.
  Instead of the multicast stuff, return a URL that points to boss'
  web server. The URL is of the form:

   https://www.myemulab.net/spewimage.php?imageid=10013&access_key=abcdef

  which as you can see is fully specified; the client does not need
  to know anything else.

* New webpage and backend scripts appropriately called "spewimage"
  which also includes support for the http HEAD request (from wget) to
  avoid downloading images that are already on the node. I just
  learned about this HEAD request stuff today ... but otherwise these
  operate as expected, spewing the image if the access key is provided.

* Changes to rc.frisbee to deal with remote loading. In addition to
  URL support, I also added support for simple paths, the intent being
  that we will probably distribute images offline (say, at night) so
  that when a node reboots it doesn't actually have to wait 60 minutes
  for an image to download. I have not added any server side support
  for this yet though. Maybe later this week.

* Other bits and pieces and fixes to make this work.

This will superceed the widearea_privkeys table that was used for
RON/Netbed but was never done well.

The privkey is just something we generate and store on the dongle (as
a simplification, we just create a dongle per node instead of
generating them on the fly) since there are not very many of these
widearea (CMU) nodes. We store the IP here for convenience (there is
an interfaces table entry of course).

The IP is updated when the node tells us it has changed, using the
privkey to uniquely identify it (for checkin).

  DB alongside the resource records. Previously, we stored only the
  nsfiles for current experiments, and purged them when the experiment
  was terminated. The new approach saves them forever using the resource
  record ID. Note that we do not store copies of NS files, but reference
  them indirectly instead so that we can MD5 them and avoid the dups.

  I put a "compressed" bit into the table cause at some point we will
  start compressing the data before storing them into the DB. Or maybe
  we bag this and start using GFS!

  Also note that this addresses the problem of losing the NS file
  history when using swapmod, since the NS file is overwritten.

* Add a pmapping table stores the nodes (and their types) used by an
  experiment. This data is also saved forever, alongside the resource
  records, so that we can more accurately replay an experiment. As Rob
  points out, the node names can also be used in conjunction with the
  ptop files that are saved, to get a 100% accurate remap of resources.

processing the node_history table, but that is *way* too slow to do on
the fly (say, from the web interface) cause of the number of records,
so the summary info is stored in the new node_utilization table. I
generate the summary info as new entries are added to node_history (in
SetNodeHistory) but if that becomes too messy, we can just as easily
shift to processing the table on a nightly basis.

Note that I added a new "inception" date field to the nodes table,
which will get set on new nodes, but for existing nodes I have to
derive it from the first entry in the node_history table, or else the
numbers will not make sense.

This change attempts to make the stats gathering code more reliable by
not relying on the testbed_stats records to reconstruct usage
statistics.  The main source of errors and total confusion in the
current stats code is that testbed_stats includes all the errors and
transitions, from which I have to reconstruct what happened in order
to determine usage by a project or user.

The new stats code still generates the testbed_stats code, but actual
usage is recorded as it happens, in the experiment_resources table, as
swapins, swapouts, and swapmods occur. Its also much faster to compute
the data for the tables in the web interface, not having to scan a
zillion testbed_stats records in php.

There is a time consuming update to the records that takes place with
a lot of tables locked.

cache latest statistics about planetlab nodes (a reduction of the
data in plab_nodehist).

deal with the issue of what a hidden run means when doing a replay, cause
more generally, replay needs a lot of work.