GitLab

1. Change initial query in instantiate.php to ask for just the few
   fields we need. Profiles have rspecs and scripts, and that is a lot
   of data to return, given that the average user has access to 300+
   profiles cause of all the ones marked public.

   But in general, there is a lot going on in instantiate.php, which is
   where most users are redirected to after login, and that causes a lot
   of delay.

2. The MotherShip uses ZFS_NOEXPORT, so when logging in we have to see
   if we have to run exports_setup. exports_setup can take anywhere from
   5-25 seconds. The login path was forcing this once a day, but in fact
   exports_setup is using a week, so lets change the test to match that.

3. Show a soothing modal after pressing the login button to keep the
   natives happy.

that they can be displayed and accounted.

This finishes, for now, #135. (If PhantomNet ever gets an AUP
page, we will re-visit.)

This reverts commit 841f1fb2.

Well, I screwed that revert up... I'll just do it the old-fashioned way

Leave the link to the AUP (when we have one), and the improvement
to the "submit" buttons. Remove the unnecessarily combative (and
not strictly true) test about students.

Added My profiles to profile picker

Commit for issue #178, adding My Profiles section to profile picker. @stoller

See merge request !18

library gave up trying to reconnect, so when we get back an error from
the event system, kill he even handle so that we try to reconnect the
next time through the loop.

to grow and grow and grow, until Mike notices.

data collected by the portal_monitor (ListResources), which now updates
the apt_aggregate_nodetypes type with the count/free info for each of
the types found in the advertisement.

1. Kill canceled instances; we allow users to "terminate" an instance
   while it is booting up, but we have to pend that till the lock is
   released. We do this with a canceled flag, similar to the Classic
   interface. But I never committed the apt_daemon changes that look for
   canceled instances and kills them!

2. Look for stale st/lt datasets and delete them. A stale dataset is one
   that no longer exists at the remote cluster (cause its expiration was
   reached and it was reaped). We do not get notification at the Portal,
   and so those dangling datasets descriptors sit around confusing
   people (okay, confusing me and others of a similar vintage).

1. Do not start a second copy of the event scheduler. This is the cause
   of all the slurm error messages on the APT cluster. Clearly this was
   wrong for DeleteNode(). AddNode is still open for debate, but at
   least now the error mail will stop.

2. Do not reset the startstatus either, this was causing web interface
   to think startup services were running, when in fact they are not
   since the other nodes are not rebooted. In the classic interface,
   node reboot does not change the startstatus either, so lets mirror
   that in the Geni interface.

indicating that the description/instructions are set withing the script.
Also added a help modal with extra detail about doc string and format.

own projects, default to the profile's project 2) Otherwise, default to
the project that the user has most recently used (the current default).
This closes issue #187.

issue #191. This closes issue #191.

Make sure I have addressed all the slow cases.

The handling of group file changes via the -G option is abysmal.
It creates a new copy of the installed group file on every group line
changed, fsync'ing after the new copy is made. On top of that, it implements
a new group list by first removing the user from all existing groups and then
reading them to every group in the new list, thereby maximizing the number of
group lines changed!

On the Emulab mothership where, for example, the "geniuser" user is in
some 450+ groups, adding them to a new group entailed changing 450+ lines
twice, resulting in over 900 copies of the 2000 line group file being
written. This took about 17 minutes.

The change here is modest, just check where the group line needs to be
changed or not before doing anything. In the case above, adding a single
group for a user, we only write the group file once. This takes about 0.8
seconds.

Since dongle boot does not PXE boot, we will not generate a PXEBOOTING
event. We also were not generating SHUTDOWN events. So a typical case
was that a wireless node would just straight from ISUP to BOOTING which
is a case I now cleverly ignore so as not to start a reboot timer ticking
if someone runs dhclient from their otherwise healthy node.

Anyway, there has been a low-hanging-fruit update of the boot dongle to
allow them to use subbosses for frisbee (otherwise they have to rely on
flaky multicast from boss via the firewall), and to load an image with
MBR3 (though newer Linux images don't work well because the FreeBSD 6.x
on the dongle cannot mount a newer Linux root FS to "slicefix" it).

If you add an "extravifs" file in the same directory as the "xm.conf" file,
they will get added to the dynamically created xm.conf file (which is why
just adding them to the existing xm.conf doesn't work!)

The interval (60 minutes) was compiled into tmcd before.

N.B.: DYNAMICROOTPASSWORD must be defined for this sitevar to have any
effect. Otherwise, the root password is *never* set to the Emulab value.
This is not a change in behavior, just sayin...

Needed this for building zapdisk for a really old FreeBSD (6.3).

In the !BOOTINFO_EVENTS world, someone making a random DHCP request would
cause a state transition to BOOTING which would start a timeout ticking and
most likely would timeout in a couple of minutes and reboot the node.

Our MBR/superblock/LVM/ZFS smashing code in rc.frisbee relied on dmesg
output to determine the local disks to call zapdisk on. However, the RE we
used assumed well ordered output like:

  da0 at mpt0 bus 0 scbus0 target 0 lun 0
  da0: <ATA WDC WD5003ABYZ-0 1S03> Fixed Direct Access SPC-3 SCSI device
  da0: Serial Number      WD-WMAYP0DPNFLM
  da0: 300.000MB/s transfers
  da0: Command Queueing enabled
  da0: 476940MB (976773168 512 byte sectors)

where we matched that last line. But due to the asynchronous nature of disk
initialization, probably due to some soon-to-be-failing disks on the d710s,
the last line was delayed and came out mashed-up with the da1 output:

  da1: <ATA WDC WD5003ABYX-1 1S02> Fixed Direct Access SPC-3 SCSI device
  da1: Serial Number      WD-WMAYP4939538
  da1: 300.000MB/s transfersda0: 476940MB (976773168 512 byte sectors)

so we didn't see da0 and didn't call zapdisk on it. This led to some LVM
metadata on /dev/sda4 leaking through to a new experiment and if that experiment
tried to setup LVM (e.g., a vnode host), it would blow up.

Now we use a sysctl call (kern.disks) to get the disk names.