GitLab

can go in before the client side.

discussion in issue #134. Only studly user see this for now, so
that we can play with phony reservations.

Grey circles when cluster status is not found

Merge request for issue #167

See merge request !16

idea why. I've added a lot of data dumps if that happens again.

appropriate for external sites. At the moment, the Mothership exposes
just the local cluster, so showing the fancy all clusters version would
just be confusing. Revisit later.

which uses netmem.

true *snmpit*, all others are imposters and have been shot.

The snmpit_test directory moved to snmpit. snmpit_old is gone.

The bigest improvement happened on day one when I took out the 20 second sleep
between vnode starts in bootvnodes. That appears to have been an artifact of
an older time and an older Xen. Or, someone smarter than me saw the potential
of getting bogged down for, oh say three weeks, trying to micro-optimize the
process and instead just went for the conservative fix!

Following day one, the ensuing couple of weeks was a long strange trip to
find the maximum number of simultaneous vnode creations that could be done
without failure. In that time I tried a lot of things, generated a lot of
graphs, produced and tweaked a lot of new constants, and in the end, wound
up with the same two magic numbers (3 and 5) that were in the original code!
To distinguish myself, I added a third magic number (1, the loneliest of
them all).

All I can say is that now, the choice of 3 or 5 (or 1), is based on more
solid evidence than before. Previously it was 5 if you had a thin-provisioning
LVM, 3 otherwise. Now it is based more directly on host resources, as
described in a long comment in the code, the important part of which is:

 #
 # if (dom0 physical RAM < 1GB) MAX = 1;
 # if (any swap activity) MAX = 1;
 #
 #    This captures pc3000s/other old machines and overloaded (RAM) machines.
 #
 # if (# physical CPUs <= 2) MAX = 3;
 # if (# physical spindles == 1) MAX = 3;
 # if (dom0 physical RAM <= 2GB) MAX = 3;
 #
 #    This captures d710s, Apt r320, and Cloudlab m510s. We may need to
 #    reconsider the latter since its single drive is an NVMe device.
 #    But first we have to get Xen working with them (UEFI issues)...
 #
 # else MAX = 5;

In my defense, I did fix some bugs and stuff too (and did I mention
the cool graphs?) See comments in the code and gitlab emulab/emulab-devel
issue #148.

Mostly ptopgen/libvtop changes to get things through assign.

Added a new virt_blockstore_attribute, 'prereserve' that can be applied to
a RW clone to pre-allocate the full amount of space allocated to the volume
being cloned. This is instead of the default "sparse" clone which could run
out of space at an inopportune time if the containing pool runs out of space.
But it doesn't work yet.

Everything is there in the front end to do the necessary capacity checks and
allocations of space, but then I discovered that ZFS doesn't readily support
a non-sparse clone! You can do this, I think, by tweaking the "refreserved"
attribute of the volume after it is created but that would have to be done
behind the back of FreeNAS and I would have to do some more testing before I
am willing to go here.

So for now, all clones are sparse and no one is charged for their usage.

Also, use new API call to create zvols.

support tables) so that we can do a better job of sending email on
errors.

morning.

crappy program that goes into loops quite readily.

fail (and generate a ton of email).

data and not sent us an image deletion, or we missed it somehow. And
when a new image with the same urn (different uuid) came in, our bug
messed up on deleting the old one. That is fixed and iminds is turned
back on.

Closes #161.

violation of what the reservation system says is allowed.

alternate for the portal.

Appeasing the Gods of 80 Columns...