GitLab

the unsigned int.

needs admin approval. I can figure this out from the data, but easier
if we just set a flag.

In the beginning, the number and size of experiments was small, and so
storing the entire slice/sliver status blob as json in the web task was
fine, even though we had to lock tables to prevent races between the
event updates and the local polling.

But lately the size of those json blobs is getting huge and the lock is
bogging things down, including not being able to keep up with the number
of events coming from all the clusters, we get really far behind.

So I have moved the status blobs out of the per-instance web task and
into new tables, once per slice and one per node (sliver). This keeps
the blobs very small and thus the lock time very small. So now we can
keep up with the event stream.

If we grow big enough that this problem comes big enough, we can switch
to innodb for the per-sliver table and do row locking instead of table
locking, but I do not think that will happen

experiments created in that project. For now, we are going to set this
on the Cloudlab project to prevent 500 users from being created on
those experiments, since thats where most people coming from the trusted
signer live.

1. Okay, 10-15 seconds for me, which is the same as forever.

2. Do not sort in PHP, sort in javascript, let the client burn those
   cycles instead of poor overworked boss.

3. Store global lastused/usecount in the apt_profiles table so that we
   do not have to compute it every time for profile.

4. Compute the user's lastused/usecount for each profile in a single
   query and create local array. Cuts out 100s of queries.

If we assign a unique constant random value to every user, and spit that
out in the initial ga() stuff at the beginning of each page load, google
can combine interactions from the same user across different devices.
Say, like work vs home computer.

have been machine converted from rspecs to geni-lib scripts.

push hook URL.

image server to delete versions.

+---------+---------+---------+---------+--------+---------------+--------+
| pid     | gid     | pid_idx | gid_idx | policy | auxdata       | count  |
+---------+---------+---------+---------+--------+---------------+--------+
| testbed | *       |   10345 |       0 | type   | d430          |     10 |

which says to apply the policy to all subgroups, using the current
count for the project.

from being deleted. If a profile cannot be deleted, then the images
it references cannot be deleted either.

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.