GitLab

is off, this is just the control net interface (xenbr0). But when
XENVIFROUTING is on, we want to listen on the control net bridge plus
all of the container vifs. Since these are not created until the
container is started, we have to call restartDHCP from emulab-cnet (we
were already doing that), and now we also call reconfigDHCP() when the
contain is destroyed so that interface list is correct (note that DHCPD
does not seem to care if an interface dissappears, or even if an
interface does not exist when starting.

The main point here, is that on shared nodes we have to restrict the
number of interfaces that DHCPd listens on (or even looks at) since it
can be 100s, and dhcpd was taking well over a minute to start up each
time.

Aside; minor change to not look at the IP config for bridges, just the
mac. Takes to long when there are 100s of bridges.

rewrite the interface list in /etc/defaults/isc-dhcp-server. We do
not need to restart DHCP, it does not mind that the vif is gone.

since the vif foes not exist yet, and we call restartDHCP() again in
emulab-cnet after the container and vif exist. In fact, no point in
restarting DHCP when removing an entry, since by that time the vif is
gone and dhcpd does not seem to mind that anyway.

1. Show current reservations on the admin extend page (if any) for the
   user who started the experiment.

2. Add a reservation history page, to see historical reservations for a
   user.

3. Changes to the reservation listing page.

4. And then the main content of this commit is that for the pages above,
   show the experiment usage history for the project and the user who
   created the reservation. This takes the form of a time line of
   allocation changes so that we can graph node usage against the
   reservation bounds, to show graphically how well utilized the
   reservation is.

1. Return current set of reservations (if any) for a user when getting
   the max extension (piggy backing on the call to reduce overhead).

2. Add RPC to get the reservation history for a user (all past
   reservations that were approved).

   Aside; the reservation_history table was not being updated properly,
   only expired reservations were saved, not deleted (but used)
   reservations, so we lost a lot of history. We could regen some of it
   from the history tables I added at the Portal for Dmitry, but not
   sure it is worth the trouble.

3. And then the main content of this commit is that for both of the
   lists above, also return the experiment usage history for the project
   an dthe user who created the reservation. This takes the form of a
   time line of allocation changes so that we can graph node usage
   against the reservation bounds, to show graphically how well utilized
   the reservation is.

that backend processes in flight do not get killed in their tracks. This
might not work right, but elabinelab testing does not tell me much, lets
see how it goes.

within a project with reservations active during an experiment.

experiment.

connect two ports. It appears that letting port alarms pile up causes
the CLI to hang every now and then for a really long time. Thats my
theory, I have at least two data points to prove it.

in the tables.

caution.

need uid_idx and pid_idx. Also store the cancel date.

Fix bug; we were not storing a history entry for deleted reservations,
so we lost all those entries even though they were reservations that
were used.

to /home (does not copy from /users), and back to /users when toggling
off.

Something about the way we upgrade apparently causes the .db files not
to get remade. This ultimately causes problems with the Emulab scripts
try to add accounts.

little file!

people delete used reservations before the expire, and currently we are
only recording expired reservations. So we need a deleted slot in the
history table to tell the difference.

(We cannot ignore interfaces without an IP; that was the critical new
problem.)

Sometimes there seemed to be a race where systemd-networkd would start
trying to find .network config files before the emulab control net udev
rules (the shell script the rule launches, rather) could actually write
them.  This race would sometimes manifest, but mostly not.

By default, systemd-networkd does not wait for udev to finish
processing its device events.  This seems odd, but I guess it is not
expecting dynamic configuration in /run/systemd/network like we use
(although its docs explicitly allow for this case).  Oh well.  `udevadm
settle` is supposed to indicate that udev is done processing all device
events; but it must not mean that it is finished processing all the
rules!  So not only do we wait for it to settle; we wait for the
appearance of at least one .network file (that we wrote, hopefully) in
/run/systemd/network .  No one else would ever write them there,
clearly.