GitLab

(This might be a bandaid for another problem with docker's attach;
I seem to get some garbage from some container stdout/stderr, especially
in this case.  Probably encoding that I'm not handling yet; but this
papers over that.)

(Of course, there is no standard perl Docker Engine API, so I wrote my
own thin perl library, basically error handling and JSON marshalling
goo.  But had to deal with LWP/http over UNIX socket to Docker, which
is whacky; fortunately, there was a module, but I can confirm that LWP
is a pain when you get off the beaten track.  Anyway, I added a little
client that is useful for debugging.)

Also, I refactored things a bit so there is now an emulabize-image
script that can be run to test emulabization of docker images
separately from vnode creation.

Also, add a specific Docker version of the prepare script.  This
actually gets run in image commit as an ONBUILD instruction.

Also, always copy the image's master passwd files into /etc/emulab
instead of using those installed by client-install.  Those just don't
apply at all here since we have no idea what the base image is; the
uids/gids in the clientside dirs could be a complete mismatch for the
image.

see.

to allow this for so long given than underscores are not legal in
DNS names.

right place. This closes issue #338.

This was blocked waiting for ops.emulab.net to need a reboot so that
we could turn on resource accounting. Now that happened and I have
done some testing, defined some arbitrary limits for other resources,
done some more testing, and here we are!

This should enable issue #247 to be closed.

Don't exit on individual failures, watch for case of switch disconneting
uncleanly from ssh.

(Invoking osload this way is a bug, but since libosload_new's wait
loop is a counter, we can't double-wait for any one node since each
node only finishes once (per image)... so we have to check this case,
otherwise the real problem is hard to debug.)

whacky options that make it a user error, puts the error at the
very top of the email, and stops the error email going to tbops.

libosload_new::osload cannot handle if it is told in one invocation to
load the same image twice on the same node.  GeniAggregate::Action was
telling it to do that if a vnode sliver was processed before a vhost
sliver; the vhost sliver would be duplicate-processed, resulting in a
double-call to osload that resulted in the osload child process hanging.