GitLab

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.

the user into their project, but now we are importing into GeniSlices as
geniuser. But if an image was already here, we will fail the permissions
checks, so tell the importer to to the update as the user that owns the
image. Might need to to actually move those images at some point.

import as the updater does not work in this case, so use the creator which
is always going to have local groups (since it is geniuser or a real
user). I need to think about why we do not do this, it dates back to the
original stuff we did for the Probe cluster, but we are now using nonlocal
users and projects n a different way for the Cloudlab portal.

see whether they are running, and their exit code if exited.

return now selects that profile.

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

as possible since we never know that this script exists with failure
on teardown.

names that are greater the Linux max of 28 characters, and make it
backward compatible with running VMs.

Our cricket graphs have been broken since January...oops.

Use tail -r instead.

thing, and it is convenient to do the setup in the context of a different
user (say geniuser, for a slice experiment), since we are now importing all
global images into the GeniSlices project. There is still another backwards
compat problem I need to think about.

array inside of the formfields array.

user doing the image snapshot. At the image origin cluster, use this URN
to set the updater urn for the new image version, and if that urn is fot
a real local user, also set the updater,updater_idx accordingly. Lastly,
the image import *must* be done in the context of a user in the project
of the image, so fall back to using the image creator.

origin cluster; this change just added the slot we need in the DB.

and always import into the GeniSlices project. Previously, images were
being imported into the project of the slice experiment, by the geniuser.

When PROTOGENI_LOCALUSER is turned off, this change does not affect
anything, since it is still geniuser doing the import, and all imported
images are consider global and thus cross-project usable. So where we stick
the image is not really important, but putting all geni imported images in
one place is more convenient (sure makes it easier to find them). But more
important, this change is backwards compatible with existing imports. 

Later, if the source image is updated, and a new user (in another project)
uses that image, the update (pulling the updated image scross) is done by
geniuser (who is the leader of all geni holding projects), who has write
access to the image whatever project it is in. 

What about when PROTOGENI_LOCALUSER is turned on? There are actually two
sub cases here.

1. The user is using an aggregate in a different domain then their SA. Say,
   when a Cloudlab Portal user is creating an experiment at the Clemson
   cluster (which has PROTOGENI_LOCALUSER=1). In this case, clemson does
   not know anything about the user anyway, and so its pretty much like the
   case described above since everything is done by the geniuser in holding
   projects owned by the geniuser.

2. The user is using the same aggregate as their SA. Say, when a Cloudlab
   Portal user is creating an experiment at the Emulab cluster. In this
   case Emulab knows the user and project, and everything is done as that
   user in the actual project (there is no geni holding project).

   If we import the image into that project as the actual user, we are okay
   at first; as above, all images are global and cross-project, so anyone
   can use it. But what if the source image changes and then a different
   user in a different project tries to use it? The backend is going to try
   to import the new version, but that fails cause the current user does
   not have write access to the image.

   Hence the real reason for this change; if always import into GeniSlices
   as geniuser, we do not get into this permission problem.

descriptor from getting created, so we fail sooner rather then waiting till
later after the resources are allocated and we discover that we are not
allowed to ete the image file.

was causing an undefined variable.

disable the console and console log option in the context menu.

parameterized profile.

tainted nodes.

Pass authinit index, not tag, to targetgroup.
Set serial number via extent, not target.