Pretty much the same as for APC, only different OIDs. Could not get
the symbolic names to work, so it is using hardcoded raw OIDs right
now. Still need to add support for power metering.

to click on the Extend button.

in the Powder portal.

(There is also a grotesque hack for noticing that an MFS needs to be
booted via an alternate pxe_boot_path.)

I noticed that when using the local portal to start an experiment, on a
cluster that is also a member of the Cloudlab federation (the Portal),
the local portal UI was not seeing the usual updates to the nodes in the
topology drawing. That is cause the events were going to the remote
Portal instead of to the local portal. This change looks at the slice
URN, specifically the domain, to decide where to send those events.

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 emulab-devel!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 emulab-devel!42

Update configure with missing racks

See merge request emulab-devel!43

Update configure.ac with more racks that were missing

See merge request emulab-devel!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.