GitLab

instead of cloudlab-ops, which we want to use for the combined cluster
email list. Send more email to logs instead of ops, now that we are
generating enough of it.

their experiments, we fall back to naming it for them.

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.

we can get at it from users of CallMethod. Then in create_instance,
put that into the APT_Instance record so that we can easily see the
log file if there is a failure. That is displayed in the status page
when in red-dot mode.

can make use of it (to tell users what nodes are up/down).

say something more informative them "read timeout" if we lose contact
with the backend cluster.

I still need to figure out what to do when this happens, At the moment we
set the status of the new instance to failed, even though it can't be
terminated until the network partition clears up.

box about keys.

1) Implement the latest dataset read/write access settings from frontend to
   backend. Also updates for simultaneous read-only usage.

2) New configure options: PROTOGENI_LOCALUSER and PROTOGENI_GENIWEBLOGIN.

   The first changes the way that projects and users are treated at the
   CM. When set, we create real accounts (marked as nonlocal) for users and
   also create real projects (also marked as nonlocal). Users are added to
   those projects according to their credentials. The underlying experiment
   is thus owned by the user and in the project, although all the work is
   still done by the geniuser pseudo user. The advantage of this approach
   is that we can use standard emulab access checks to control access to
   objects like datasets. Maybe images too at some point.

   NOTE: Users are not removed from projects once they are added; we are
   going to need to deal with this, perhaps by adding an expiration stamp
   to the groups_membership tables, and using the c...

create_instance, now that user can manage multiple keys.

UI to not use modals.

all users. Cloudlab added to the list, but not exposed except to
admins and studly users.

function has been moved into manage_instance and its associated library
(APT_Instance). Lots of cleanup of the code and more use of webtasks to
communicate with the web server.

certificate or an expired certificate, create a new one automatically.
We will reuse the private of an existing but expired certificate.

trust our certificate.

then just success/failure. For example, lets tell the user if the reason
for failure is lack of nodes.

the slice name, if the user uid does.

limit of 5 days. Pass that along in the list of credentials.

box, but as a collapsible. Warn user if they do not have a key (provided on
signup page) that they are restricted to browser shell. Whenever user
provides a key, replace in the database (if its changed). This keeps the
user out of the Emulab interface to edit their ssh keys. Might have to
revisit this if APT/Cloud users need/want more then the one key.

can tell which interface (APT or CloudLab) was used to create an instance.
Don't want to have to go back and parse email.

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