GitLab

1. Encapsulate rspec2genilib in a library function.

2. Add a "check" option UpdateDiskImage() to see if any changes are
   actually going to be made so that we do not create a new version of a
   profile that is identical to the previous version.

3. Do not ever create a new version of a script based profile since we
   can never change the script (after a disk snapshot). Unless it is a
   portal converted script, we can do that by changing the rspec and
   then generating a new script.

Redo the rspectogenilib converter with the goal of supporting both
translation *and* regression testing. A new library is responsible for
taking the output of libXML and creating a data structure representing
the rspec. While this is being done, we look for any constructs or
attributes we cannot handle with geni-lib and report that as an error;
we are not going to convert an rspec unless we can do it correctly. and
completely.

Regression testing is done with another part of this library, that knows
how to compare each element of two rspecs. Basically start at the root
and compare all the way down, failing if the two "parses" of the XML are
not equal at any level.

rspectogenilib now has an option that does regression testing by running
the new geni-lib and comparing the resulting rspec against the original.

On the UI side, there is a new button on existing rspec based
profiles (currently only for admin and studs) called "Convert to
geni-lib" that runs the converter to convert the profile to geni-lib.
The user does not have to accept the new script of course.

However, a converted profile is marked in the database, and the user can
still use Jacks on it, we just run rspectogenilib geni-lib again on the
new rspec. If the user edits the geni-lib, we switch back to normal
geni-lib (clear the flag) when the new version is saved, and Jacks is
once again read-only. This is explained in the UI, and is one of the
things people need to give comment on.

There is also a mode on the Create Profile page for converting new rspec
based profiles to geni-lib, but that is fully turned off for now, we can
get to that later.

Fix error-handling errors.
Make the waitwait modal non-dismissable everywhere.
The new genilib-editor is now a kind of mega-modal which can live in both the show-profile and modify_profile pages. It is read-only in the former case and read/writable in the latter.

All of the form-submitting stuff that recent ajaxification broke has been stripped out. It is now a pure editor that notifies the surrounding page of changes when you click on 'accept'.

sees errors properly.

snapshot operation (that manage_instance already took). This is so we
can ask the user if any new accounts have been created when doing a
clone (we already do that we snapshot).

We are running another apache server on boss, on port 51369, which
invokes a backend perl script that maps the URL path argument to the
profile, and then calls out to manage_profile to pull from the
repository and update the profile to reflect the new HEAD branch.
Using mod_rewrite in the apache config to restrict URLs to exactly
the one URL that is accepted, modulo the value of the secret token.

I had to refactor a bunch of code in manage_profile to make it easier to
add a new entrypoint for modification from a git repo. This needed to be
done for a long time, I had never cleaned up the original profile
creation code.

On the edit profile web page, there is a new row in the Repository panel
providing the Push URL, and an explanatory help modal.

There is a new slow polling timer that looks for a change to the repo
hash and causes the web page to update in place from the repo, as when a
push hook is invoked and changes the repo.

for testbed,tbres,utahstud.

after updating the rspec with the new image urn after a snapshot.

all at once, we want to delete the naked images so that all versions of
the image get deleted.

Here is where things get tricky; our only record of where the image
lives and hat versions exist is at the cluster or in the source. But
if the source is not using a version then we have no record of it and
do not know what cluster to delete from. This is problem on the Cloudlab
portal not the Emulab portal, we can handle that (although I do not
yet).

Still working on this, but its a little better and of course images can
be deleted on the image management page which asks for a complete list
of all images.

profile deletion.

image versions at the clusters.

when they have leaked.

remove are run on ops via the proxy script. Other smaller operations
like getting the source, logs, commit info are currently run on boss via
NFS to /usr/testbed/opsdir/repositories, which are one per profile.
Lots of work still to do on optimizing repositories.

not happy with that part yet.

Also includes some PhantomNet-specific restrictions (e.g. only
allows use of the main Utah Emulab testbed  aggregate).

This excercise stretched the limits of what we can reasonably do
before introducing real per-testbed branding/policy mechanisms to
the php/web front-end.  My changes ain't exactly pretty...

Please take care when adding any testbed-specific changes to the
code.  There are three flavors now to consider in the logic.

intended to finish, but never did. Unfortunate since we have lost some info
that might have been useful.

In addition, we now record provenance on a plain profile copy, in addition
to a clone.

Fixes to the profile history display, and add a new pointer to the profile
derived from when it is not null.

changes and some checks to prevent a user from instantiating a disabled
version.

user needs to see the error.