GitLab

1. Do not allow guest users to use anything but the APT cluster. We had
   talked about this a while back, and today it caused a problem:

2. Because a guest tried to use the Mothership (cause of a URN in the
   profile), we had GeniUser lookup confusion. We store guest users in the
   geni-sa geni_users table, but because PROTOGENI_LOCALUSER=1, we end up
   creating a nonlocal account on the Geni path, and that conflicts.
   Changed how we do lookups.

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.

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

same cluster.

control network port modification), and add front end support to the Portal
status page (admin mode only of course)

Also includes some PhantomNet-specific restrictions (e.g. only
allows use of the main Utah Emulab testbed  aggregate).

This excercise stretched the limits of what we can reasonably do
before introducing real per-testbed branding/policy mechanisms to
the php/web front-end.  My changes ain't exactly pretty...

Please take care when adding any testbed-specific changes to the
code.  There are three flavors now to consider in the logic.

intended to finish, but never did. Unfortunate since we have lost some info
that might have been useful.

In addition, we now record provenance on a plain profile copy, in addition
to a clone.

Fixes to the profile history display, and add a new pointer to the profile
derived from when it is not null.

changes and some checks to prevent a user from instantiating a disabled
version.

waiting till it finished setting up (or fails). This is really nice when a
1000 node experiment has gone awry and it is pointless to wait for it to
finish. When we do this, we mark the instance as canceled in the DB, and
then wait for create_instance() to notice it. When it does, it stops
waiting and invokes terminate with a new cancel option at the backend.

wait time to 15 minutes, but watch for progress. Any time a node changes
bump the waiting time above five minutes. Just a start point, lets
see how it goes.

big topologies.

Terminate. The read failure is harmless (the Terminate happens just fine)
but lets avoid the errors locally.

1. Instead of a plain list of profiles, generate a more detailed list that
   includes last used and usage counts and project name and favorite flag,
   so that the new picker can be sorted/grouped.

   This list is *ordered* by most recent usage (if a real user), or most
   popular (if a guest). 

2. Move the modal from quickvm_sup to the template, and generate the
   current list from the new json info.

3. Add new table apt_profile_favorites to record favorite profiles for
   users.

4. Add new ajax calls for above, MarkFavorite and ClearFavorite that take a
   single argument, the uuid of the profile. There is no UI for this, Keith
   is going to add that.

blocking option (strictly an IG thing) so that we do not delete the
local instance record until the remote slices are gone. This avoids
name clashes in the Portal where we allow a user to reuse a name
before its really gone, causing obscure errors.

with BADARGS; stitcher always exists with 1, and I've not been able to
fix that.

dashboard page.

errors page after the instance has been deleted.

errors table so that we can show them in the dashboard.

to be decrypted using the per-exp ssl keypair we create and store on the
nodes. In this case, you can add this to your rspec in the node element.
You can add as many as you want, use the name attribute. We generate a
random password and encrypt the plain text:

  <emulab:password></emulab:password>

which becomes:

    <emulab:password name="foo" encrypted="true">-----BEGIN PKCS7-----
MIIBpAYJKoZIhvcNAQcDoIIBlTCCAZECAQAxggFMMIIBSAIBADCBsDCBqDELMAkG
A1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5
MR0wGwYDVQQKExRVdGFoIE5ldHdvcmsgVGVzdGJlZDEPMA0GA1UECxMGQVBUTEFC
MRcwFQYDVQQDEw53d3cuYXB0bGFiLm5ldDEoMCYGCSqGSIb3DQEJARYZdGVzdGJl
ZC1vcHNAZmx1eC51dGFoLmVkdQIDAs8NMA0GCSqGSIb3DQEBAQUABIGAKeyo7mPO
rHRF2G9t0h8/ALBBh7ChD1zCYvRFi2qvvUIIv/kfCNPhujRfodIYR65dP3tfM+BH
VTRxjJrMYH63m8Fz9KMZlVYn+DhMeiwerqTxvVs823zyxcDrOUzTzzakWmJVSqvl
33Po/7CYZ2iq67ATF1Xym3DsRQbQSuwgzu8wPAYJKoZIhvcNAQcBMB0GCWCGSAFl
AwQBKgQQRw0kmvwhIur/ZlfFbB75qoAQXTKjzwN1HDJW4x5GAcWNPA==
-----END PKCS7-----
    </emulab:password>

which can then be decrypted using the private key to get the plaintext
password.

when there is an error so that we can more easily find it when reviewing
the apt_instance_failures table.

exitcode and the exit message (the one we show to the user). Show the
counts on the dashboard page.

For now, I am not breaking out the errors on the dashboard page. Need
to think about how we break them out, also do we want to show any details
about failures.

the jacks image constraint code is operating nicely.

1. Use information from sliverstatus to indicate that nodes have startup
   execution services running, and then tell then when they have finished,
   and they exited with non-zero status, indicate that they failed. We also
   hold saying the "ready" in the upper panel until all the services have
   exited, we say "booted" instead, and also say that nodes are running
   startup services.

2. For snapshot, when we know an image has to be copied back to its origin
   cluster, tell the web interface, so that we can add another step to the
   imaging modal ("copying"). We know the copy is done when the origin
   cluster has posted the new image data to the IMS, so we do an additional
   poll in the backend waiting for the image server to get the data, and
   then we mark the image as ready for use.

this check, now that the image server and jacks constraints are working.