GitLab

Also, get rid of a 5 second timeout where it wasn't needed and add
more timestamps.

Disabled for now. This is a checkpoint. This version still downloads
the compressed image into a volume and imageunzips into another volume.
The difference is that only one client does the imageunzip and then
everyone makes a snapshot of that.

On to getting rid of the initial download of the compressed image...

the -i option, so as not to be confused by the invoking user's ssh
agent.

Also, switch to an rsa version 2 key for the initial keypair, time
to stop using protocol 1 keys!

box about keys.

The /proj and /groups directories don't exist for unapproved projects
and that was causing mountd to get all uppity.

You can now simultaneously RW and RO map a dataset because all the RO
mappings use copies (clones) of a snapshot. Only a single RW mapping
of course.

When the RW mapping swaps out it automatically creates a new snapshot.
So there is currently no user control over when a version of the dataset
is "published", it just happens everytime you swapout an experiment with
a RW mapping.

A new RW mapping does not affect current RO mappings of course as they
continue to use whatever snapshot they were created with. New RO mappings
with get the most recent snapshot, which we currently track in the DB via
the per-lease attribute "last_snapshot".

You can also now declare a lease to be "exclusive use" by setting the
"exclusive_use" lease attribute (via modlease). This means that it follows
the old semantics of only one mapping at a time, whether it be RO or RW.
This is an alternative to the "simultaneous_ro_datasets" sitevar which
enforces the old behavior globally. Primarily, I put this attribute in to
prevent an unexpected failure in the snapshot/clone path from wreaking
havoc over time. I don't know if there is any value in exposing this to
the user.

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.

are a pain since access is not by credential or user.

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.

tipline will not exist until the VM is running (since the capture runs on
the physhost), but that that is too late for inclusion in the manifest.
Need a better mechanism.

can create an experiment for another user.

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.

can get it easily.

which looks at environment variable to determine what user should be used
for access checks. Now used from the protogeni interface, when real
accounts are in use (but all work still done by geniuser).