GitLab

local accounts on the backend cluster; images might be used from
a different project then it was created (say for guests or for
someone in a different projet using your image. This is workaround
for now, until I figure out what to do.

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 credential expiration to
   mark it.

   The second new configure option turns on the web login via the geni
   trusted signer. So, if I create a sliver on a backend cluster when both
   options are set, I can use the trusted signer to log into my newly
   created account on the cluster, and see it (via the emulab classic web
   interface).

   All this is in flux, might end up being a bogus approach in the end.

interactions with versioning that need to be worked out, since only
the head version can be deleted.

create_instance, now that user can manage multiple keys.

experiment_stats.

UI to not use modals.

and rspec that are used. This is to support Parameterized Profiles, where
the rspec is generated from a geni-lib script and user defined parameters.

Add manifest to apt_instance_history; I was not storing the manifest cause
I figured we could just ask the backend cluster for it. Well, that is kinda
silly, so lets store it locally. I'll have to go back and grab the
manifests for the current history entries.

Add isaptkey to user_pubkeys so that we can mark the key that comes in from
the instantiate page. This lets us keep the Emulab keys for a user
independent of the APT key, so that APT users only deal with a single key
on that path, without messing up their Emulab keys.

up the embedding so that its less confusing.

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

Project leases are now per-group, so we build a sub authority certificate
for a remote dataset so that on the remote side, it is created inside the
group named by the project on the local side.

Many bug fixes.

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.

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.

places.

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

* Add a uuid to the profile itself. So now we have a uuid for each specific
  version, and a uuid that points to the profile as a whole.

* On the manage page, move the URL to the left hand panel, and add a second
  URL. One is the URL of the specific version, and the other is a URL to
  the entire profile. Add popovers to explain the difference between.

* On the instantiate page, when you use this URL, we instantiate the most
  recently published version of the profile.

* Add a bit of verbiage to the publish modal.

support code.