GitLab

that code on the geni racks.

service actually had a command in it.

not have set the Monitor flag on that aggregate.

(Since the call to ipodinfo in fullconfig resets the hash.)

elabinelab setup issues.

Incorrect VM count reported in Xen4.9 monitoring code

See merge request !45

Not sure if it's a Xen4.9 feature or a bug, but Dom0 also shows up in the list of VMs when doing an "xl vm-list". Xen4.6 and older did not. The VM count reported was incorrect(1 extra because of Domain-0) in Xen 4.9. Added a grep to fix this and is backward compatible.

Fix minor typo

See merge request !42

Update configure with missing racks

See merge request !43

Update configure.ac with more racks that were missing

See merge request !44

Part of the Power Panic Button.

tailored to the portal; for example, the layer1 and stitching profiles
are not shown in the Emulab Portal, but only in the Cloudlab portal.

state (say, from valid to grace). Also, change the refresh interval for
expired datasets to hourly instead of every five minues.

switches, I must have forgot to deal with it.

Basically, the FTOS manual says you can give it an MD5 or sha256 hash of
the password. Well, FTOS must come from another dimension, cause the MD5
and sha256 it generates, is different then what boss generates, for the
same input string. So that makes it hard to set up an account with a
password, unless I send over the cleartext. Which is okay, it stores it
internally as the hash (I cannot seem to generate). So we send over the
cleartext per-node root password that is regenerated for each time it is
allocated to an experiment. Not a big deal, we load the user's ssh keys,
they should not need to use passwords.

Otherwise you get a lot of this action:

WARNING: 10.254.254.203 (iqn.1993-08.org.debian:01:5ad48b44316d): session reinstatement from different address 10.254.254.201

The issue was that we would restart iscsid after changing the name, but if the
iSCSI sessions were already open, the name change would not immediately take
effect (til next reboot).

This will happen if the open-iscsi and/or iscsid service is started at boot time
prior to the Emulab blockstore config running. We explicitly turned these services
off in Ubuntu 14, but not in 16 and above cuz that would involve interaction with
systemd and some of us don't speak systemd. Anyway, this will work even if the
services are enabled at boot.

ignored.

power off panic.

* Add a new Portal context menu option to nodes, to boot into "recovery"
  mode, which will be a Linux MFS (rather then the FreeBSD MFS, which
  99% of user will not know what to do with).

* Plumb all through to the Geni RPC interface, which invokes node_admin
  with a new option, to use the recovery mfs nodetype attribute.

* recoverymfs_osid is a distinct osid from adminmfs_osid, we use that in
  the CM to add an Emulab name space attribute to the manifest, that
  tells the Portal that a node supports recovery mode (and thus gets a
  context menu option).

* Add an inrecovery flag to the sliver status blob, which the Portal
  uses to determine that a node is currently in recovery mode, so that
  we can indicate that in the topology and list tabs.