GitLab

We will populate this with the info we currently hardwire in the
rc.d/3.mfrisbeed.sh startup script. Will pass to the subboss via
a new tmcd call or using the mothballed subboss XMLRPC interface.

of these now, time to start managing them properly (we have lots of stale
ones in the DB).

interfaces table that tells snmpit not to mess with the port.

ports that do not support our oldish set of speed/duplex settings.

1. We do not need to save the param definitions; we have the script.

2. We do want to save the refspec in the history, even though we have
   the hash. Easier to see what is going on.

elabinelab creation will work.

monitoring system.

New portal_monitor daemon does a GetVersion/ListResources call at each
of the clusters every five minutes, and updates the new table in the
DB called apt_aggregate_status. We calculate free/inuse counts for
physical nodes and a free count for VMs. Failure to contact the
aggregate for more then 10 minutes sets the aggregate as down, since
from our perspective if we cannot get to it, the cluster is down.

Unlike the jfed monitoring system, we are not going to try to
instantiate a new experiment or ssh into it. Wait and see if that is
necessary in our context.

On the instantiate page, generate a json structure for each cluster,
similar the one described in issue #172 by Keith. This way we can easily
switch the existing code over to this new system, but fail back to the
old mechanism if this turn out to be a bust.

Some other related changes to how we hand cluster into the several web
pages.

distinguish original creator from updater.

do reservations.

support tables) so that we can do a better job of sending email on
errors.

we do not actually have it when we create the table row.

change as I get further into it.

clusters using credentials to provide permission to access the datasets.

* Add authority_urn to the images table, which is the urn of the origin
  dataset (similar to the slice urn, the Portal mints a credential in
  its namespace, so that the Portal always has permission to do anything
  it wants to the dataset at the remote cluster).

* Add slot to the apt_datasets table to store a credential from the
  cluster where the dataset lives. This credential gives the owner
  permission to download the dataset, which the portal will delegate to
  any cluster that might need to get that dataset.

but will delete the old field after testing.

Needed for reservation metadata, useful for elastic slice node
assignment and hopefully other things.

a (slightly) larger selection of NFS mount options, then just yes/no.

more info.