GitLab

Note that this does not fix the problem I was chasing (that is fixed
by the emulab_config change just commited), but it is still a good idea.

When using AMD, the uploader path wound up "realpath"ed in the form
of /.amd_mnt/ops/... which is the location at which AMD does the NFS
mount when triggered. However, if the mount times out, that path is
no longer valid.

So for the AMD case, we have to strip the AMD prefix from the path.
This ensures that subsequent stats and other accesses of the path go
through the AMD mountpoint (e.g., "/proj/foo") and not the NFS mountpoint
(e.g., "/.amd_mnt/ops/proj/foo"), and thus trigger AMD to do the NFS mount.

(Also, sometimes the list of images supplied to libosload_new will be
null, like in the case where we want to just reconfigure a switch.  So,
handle that safely.)

First, firmwares are bigger and take longer to write, so bump the TFTP
load timeout to 5 minutes instead of 2.

Second, newer HP firmwares won't let you load unsigned firmware images
into flash, unless you specify a special param in your flash command.
Unfortunately, older firmwares don't support that param.  So we just use
trial and error to figure out if a switch has it or not, and we always
are willing to flash unsigned firmwares... just have to trust, because
we have no way of knowing which version should be signed, or how to tell
which version a particular blob is.  At least not that I know of, not
that I looked hard.

Finally, our expect-based interface has to be a bit more flexible
with some of the regexps it looks for.

libosload_new wasn't accepting the "new" types of ways to specify
one or more images to load on nodes, so manual os_load wasn't
working.  I also mirrored the usedefault and usecurrent stuff from
libosload into libosload_new; will make it easier in the future.

A couple queries were trivially broken, and the code to grab
project/group info was wrong.

reboot/reload/refresh busy errors to the user instead of us.

(The bulk of the code is in the parameter form formatter/decorator JS
code; I only applied it to the wizard for now... but it's
straightforward to copy it into the old parameter code ;))

The portal can now render the parameter form in much more complex ways.
It supports a notion of advanced parameter groups, a panel containing
parameters that is closed by default but expandable; generic parameter
groups; per-parameter detailed helpdocs in an expandable subpanel (and
an expand-all-help link that will also expand all the parameter group
panels), and error messages and warnings.  A summary of both errors and
warnings is displayed at the top of the form, and specific error message
details are displayed near parameters.  The error message display is
flexible to generic user messages -- basically if the error is a proper
geni-lib portal error/warning, but not a parameter error/warning, it
will be displayed at the top of the parameter form (along with any
others).  If it's an "improper" one, we'll still do our best to display
it.  If you warn a user, you can provide a set of parameter values that
"fix" the warning, and the Portal UI will change the form values and
tell the user it did so.  You can't do this on error; the assumption is
the user has to fix the error.

Finally, the portal now tries to rungenilib in warnings-are-fatal mode
the first time parameter bind (to generate rspec) is attempted.  If they
go backwards to re-parameterize, warnings should be fatal again.  It's
too hard to figure out when we should stop warnings-fatal mode; we can't
block the user's progress if they really want to proceed in the face of
warnings.

from all clusters, and regen the json files. Still need to add live
updating.

NOTE: This is not ready yet, Rob needs to figure out why the labels
are broken.

1. Provide text box to add to email message that is sent to user.

2. Track outstanding admin required requests, add a Deny button for those.

3. Add option to experiment listing for admins, to see outstanding admin
   required approval.

to make sure that the vinterfaces do not go into the vlans members list
or else snmpit is very unhappy.

Useless for two reasons:

1) It just takes them back to a page they already had to go through to
log in

2) For some reason, it was linking the pre-release version of the site,
before it went live, so the link was wrong anyway!

its a dismissable alert.

Really this is more for FreeNAS 9.

manifest info that David needs for the openstack profile.