GitLab

Also add an admin option from the Class page.

that has nothing in it (yet), and a link to the Emulab page until we have
something in the admin section.

at all participating clusters. Not finished yet, but good enough to let
people at it.

Includes password, so that link is gone from the actions menu.
Note that Portal users can change their email now, since we do
the email verification dance.

* 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.

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

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.

Given a password element in the rspec:

	<emulab:password name='foo'></password>

which the portal has converted to an encrypted secret, when that experiment
is later shown (the status page), ask the server to decrypt the block, and
then replace the string "{password-foo}" in the instructions with the
actual password.

Need to generalize this a bit more, for arbitrary encryption blocks, when
we have those.

code so that it does less copying of html around, and less magic. It also
does all its work via ajax and checks form values along the way instead of
all at once at the end.  Guest verification works in this version.

ajax backend for getting the image constraints, including image permission
checks. Also changes to the cluster dropdowns for the case that no clusters
are allowed. Add double click prevention, this was bothering me every time
I saw someone do it. Add a check to make sure that all clusters dropdowns
are actually selected, else do not allow the submit.

1. Provide text box to add to email message that is sent to user.

2. Track outstanding admin required requests, add a Deny button for those.

3. Add option to experiment listing for admins, to see outstanding admin
   required approval.

We now ask the portal for a the user's project membership list, and if the
user is not a member of any (unexpired) projects, we do not allow them to
create experiments (or much of anything else) in the Cloud Portal. I did
this by setting the local holding project trust to "user" and setting the
webonly bit in the users table. The user can use the picker to see public
profiles, but the create button tells them no dice, go join a project at
the GPO portal.

We make the project check each time the user logs in via the trusted
signer.

password to collapse above the console window, inside the tab.

use the results of sliverstatus to paint the nodes green as them come up
(or red if they fail).

Add context menu to nodes in the view, removing hardwired ssh on click.
The context menu has new Reboot option and console option, in addition to
the ssh option. Rework the listview to show same menu.

UI to not use modals.

up the embedding so that its less confusing.

logins like unapproved user, expired password, etc. Needs some work
though, since the auth code is not branded, and so the links are wrong.
Will do that next, but want to get this in right away.

used to manage local blockstores (datasets). A cheesy iframe hack is used
to embed the APT pages (slick new interface) inside the antique Emulab
interface.

Currently the only hooks from the admin drop down menu, since there is some
additional work before we let users see it.

leaders go through Emulab interface. Leader will get email like this:

You can approve or reject this user:

Approve:  https://www.cloudlab.us/approveuser.php?uid=leebee67&pid=lbsbox&action=approve
or
Deny:     https://www.cloudlab.us/approveuser.php?uid=leebee67&pid=lbsbox&action=deny

And clicking on one of those links will do the deed.

authenticate Geni users to CloudLab (who do not have Emulab accounts).
CloudLab users must have an account to do anything (unlike APT which allows
guest users). But instead of requiring them to go through the Emulab
account creation (high bar), let then use their Geni credentials to prove
who they are. We then build a local account for that new user, and save off
the speaksfor credential so that we can act on their behalf when talking to
the backend clusters (and their MA to get their ssh keys).

These users do not have a local account password, so they cannot log into
the web interface using the Emulab login page, nor do they have a shell on
ops.

Once authenticated, we put the appropriate cookies into the browser via
javascript, so they can use the Cloud (okay, APT) web interface (they
appear logged in).

I make use of the nonlocal_id field of the users table, which was not being
used for anything else. Officially, these are "nonlocal" users in the code
(IsNonLocal()).

When a nonlocal user instantiates a profile, we use their speaksfor
credential to ask their home MA for their ssh keys, which we then store in
the DB, and then provide to the aggregate via the CreateSliver call.
Note that no provision has been made for users who edit their profile and
add keys; I am not currently expecting these users to stumble into the web
interface (yet).

and instantiates the profile as a guest user, as for testing.

allows the user to create a new disk image in place, instead of having
to create a new profile (Clone).

and new ajax handling.